Bir ünite testi kolay olacak bir oyunun yazılımı nasıl tasarlanır?

Oyun geliştirme durumunda JUnit gibi bir test çerçevesi kullanmak pratik midir? Oyununuzu daha test edilebilir hale getirmek için ne tür tasarım konularını takip edebilirsiniz? Oyunun hangi bölümleri test edilebilir / test edilmelidir ve insan testine hangi bölümler bırakılmalıdır?

Örneğin, oyun döngüsü bir işlevde kapsüllenmişse, test edilmesi çok zor olacak gibi görünüyor. Zaman deltası süren ve oyun mantığını ileri doğru hareket eden bir "güncelleme" işlevini yeniden düzenlemeyi seviyorum; Bu, sahte, yavaş zaman deltalarını besleyerek oyunu yavaşlatma yeteneği gibi bazı ilginç oyunlara izin verir.

TDD'nin ilkelerinden biri, TDD'nin bazı durumlarda tasarımınızı etkilemesine izin vermenizdir. Sistem için bir test yazarsınız, daha sonra bu testi geçmek için kodu yazın, bağımlılıkları mümkün olduğunca sığ tutun.

Benim için, birim testinin bir parçası olarak test etmediğim iki şey var:

İlk önce görsel unsurları ve nasıl göründüğünü test etmiyorum. Bunu test ettim ve nesne güncelledikten sonra doğru yerde olacak, bir kamera sınırlarının dışında bir nesneyi cilalayacak, dönüşümler (en azından gölgelendiriciler dışında yapılanlar) grafik motoruna teslim edilmeden önce doğru bir şekilde gerçekleştirilebilecek , ama grafik sistemine çarptığında çizgiyi çiziyorum. DirectX gibi şeylerle alay etmeye çalışmayı sevmiyorum.

İkincisi, ana oyun döngüsü işlevini gerçekten test etmiyorum. Makul bir delta geçtiğinde her sistemin işe yarayacağını ve ihtiyaç duyulduğunda sistemlerin birlikte çalıştığını test ediyorum. Sonra her sistemi oyun döngüsünde doğru delta ile güncellerim. Aslında her sistemin doğru delta ile çağrıldığını gösteren bir test yapabilirdim, ancak çoğu durumda bu fazladanlamayı buluyorum (deltanızı almak için karmaşık bir mantık yapmadığınız sürece, o zaman fazladan ödeme yapılmaz).

Noel Llopis, aradığına inandığım ölçüde birim testini yaptı:

• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-2
• http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-3
• http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
• (ayrıca TDD hakkında başka birçok makalesi var)

Tüm oyun döngüsünün test edilmesiyle ilgili olarak, kodunuzdaki işlevsel gerilemeleri önlemek için başka bir teknik var. Buradaki fikir, oyununuzun kendisini bir yeniden oynatma sistemi ile oynamasını sağlamaktır (örneğin, ilk önce oynatıcı girişlerini kaydeder ve sonra bunları farklı bir çalıştırmada tekrar oynatır). Yeniden oynatma sırasında, her kare için her nesnenin durumunun bir anlık görüntüsünü yaratırsınız. Bu devlet koleksiyonuna daha sonra "altın görüntü" denebilir. Kodunuzu yeniden gözden geçirirken, tekrar oynatmayı çalıştırın ve her karenin durumunu altın resim durumuna göre karşılaştırın. Farklıysa test başarısız olmuştur.

Bu tekniğin faydaları açık olsa da, dikkatli olmanız gereken birkaç şey var:

• Oyunun deterministik olması gerekiyor, bu yüzden sistem saatine, sistem / ağ olaylarına, deterministik olarak ekilmemiş rastgele sayı üreteçlerine bağlı olarak dikkatli olmalısın. vb.
• Altın görüntünün oluşturulduktan sonraki içerik değişiklikleri, altın görüntünüzle yasal farklılıklara neden olabilir. Bunu çözmenin bir yolu yok - içeriğinizi değiştirirken altın görüntünüzü yeniden oluşturmanız gerekir.

Hem Jeff'in hem de jpaver'ın yorumlarına katılıyorum. Ayrıca, mimariniz için bir bileşen model benimsemenin test edilebilirliğini büyük ölçüde artırdığını da eklemek istedim. Bir bileşen modelinde, her bir bileşen tek bir iş birimi yapmalı ve izolasyonlu (veya sınırlı sahte nesnelerle) test edilebilir olmalıdır.

Aynı şekilde, oyunun varlıklara dayanan diğer kısımları da sadece çalışacak bileşenlerin bir alt kümesine dayanmalıdır. Uygulamada bu, bu alanların test edilmesini kolaylaştırmak için genellikle birkaç sahte bileşenle alay edebildiğiniz veya test amaçlı kısmi varlıklar oluşturabileceğiniz anlamına gelir. Örneğin, görüntü oluşturma ve girdi bileşenlerini dışarıda bırakırsınız, çünkü bunların fizik testine gerek duyulmaz.

Son olarak, oyun dünyasındaki bazı insanlardan arayüzlerle ilgili aldığınız performans önerilerini görmezden gelirdim. Kodları arayüzlerle iyi bir şekilde yazın; yolun aşağısındaki performans sorunlarıyla karşılaşırsanız, sorunu çözmek için kolayca profil oluşturabilir, tanımlayabilir ve düzeltici olabilirsiniz. Noel'in arayüzlerin performans etkisi veya ekledikleri karmaşıklık yükü hakkındaki endişeleri beni ikna etmedi.

Bununla birlikte, her küçük şeyi bağımsız olarak test etmek için denize atmayın. Testlerin ve tasarımın çoğu şey gibi, doğru dengeye oturtulması ile ilgilidir.

OP'nin, kullanıcının birim sınamalarını değiştirebileceği yorumuna yanıt olarak ikinci bir cevap ekleyeceğimi düşündüm. Ünite testlerinin amacı kaliteyi sağlamak değil, bunun tamamen yanlış olduğuna inanıyorum. Programınızın kalitesini sağlamak için testler yapmak istiyorsanız, senaryo testlerini araştırmanız veya mükemmel izlemeye yatırım yapmanız gerekir.

(Mükemmel izleme ve bir servis olarak çalışan bir ürün ile müşteriye biraz "test" yapmak zor olabilir ancak hataları hızlı bir şekilde algılayan ve sorumlu değişiklikleri geri alan sofistike bir sisteme sahip olmanız gerekir. küçük bir geliştirme ekibi.)

Birim testlerinin ana yararı, geliştiriciyi daha iyi tasarlanmış kod yazmaya zorlamalarıdır. Test işlemi geliştiriciyi endişeleri ayırmaya ve verileri kapsamaya zorlar. Ayrıca geliştiriciyi arayüzleri ve diğer soyutlamaları kullanmaya teşvik eder, böylece yalnızca bir şeyi test eder.