C # / XNA Oyun Projesini Test Etme

Programlamaya başladığımdan beri oyun geliştirmeye devam ediyorum, ama asla çok ciddiye almadım. Bir iş uygulaması geliştiricisi olarak çalışıyorum, ancak boş zamanlarımda bazı oyunlar üzerinde çalışıyorum.

İş dünyasında (Microsft web-dev yığınında) ASP.NET MVC, arayüzün çalışma şeklini birim test etme kolaylığı nedeniyle gerçekten popüler hale geliyor.

Bir oyun yazmak için hangi tasarım modellerinin (MVC, MVP, MVVM, vb.) Tüm oyun mantığının kolayca birim test edilebilir olduğunu merak ediyorum. Bu mümkün mü yoksa uygulanabilir mi? Zamanımı boşa harcıyorum, tam testler yapmak ve daha sonra birim testleri yerine "entegrasyon" türü testleri çalıştırmak daha mı iyi?

Örnek kod iyi olurdu, ancak bir yazma da yararlıdır.

(Birim testi etiketi eklemeye çalıştım, ancak destek teknisyenine gerek yok ...)

— Nate
kaynak

İşte, kolayca yeniden kullanılabilir hale getirmekle kalmayıp aynı zamanda birim testi yapmak için çok daha kolay hale getirmek için işlevselliği ayırmak için bir mimariyi açıklayan iyi bir makale:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Bazı oyunlar MVC benzeri bir modelden yararlanır. Satranç ve kart oyunları gibi masa oyunları akla geliyor. Bununla birlikte, çoğu durumda, bu büyük bir aşırılıktır.

Şahsen ben sadece doğada algoritmik olan şeyleri birim test etmenin yeterli olduğunu düşünüyorum. Oynanış kodu yazarken "sadece işe" güveneceğiniz şeyler ve eğer çözülmezse sorunları izlemek sinsice zor olabilir. Kavşak testleri veya ağ kodu gibi şeyler.

(İdeal olarak 3. taraf bir çerçevede oluşturulacak, böylece bunları yazmak veya test etmek zorunda değilsiniz !)

Oyunla ilgili şeyleri birim testi için kullanmak istediğim bir teknik, "görsel birim testi" olarak adlandırdığım şeydir. Temel kavram, söz konusu kod bitinin (örneğin bir kavşak işlevi) basit bir satır oluşturma ve girişleri işlemek için bazı temel tuş veya fare atamalarıdır. Hiç kimse, birim testlerinin otomatikleştirilmesi gerektiğini söylemedi - sadece işleri ayrı birimlere ayırıp test etmek zorundalar.

— Andrew Russell
kaynak

İyi cevap. Ben de tam olarak bu makaleyi yayınlamak istedim. Oyun Nesnesi bileşen sistemleri mantığı ayırmak ve bunları tek tek test etmek için harika bir yoldur. Bununla birlikte, hiçbir birim testinin yapamayacağı şey, gerçek zamanlı olarak rastgele sırada etkileşen çoklu oyun mantığı yollarının karmaşık etkileşimleridir. Bu, hava tahminlerini birim test etmeye çalışmak gibi bir şey. :)

— LearnCocos2D

Evet, ayrıca belirli işlevsellik parçalarını izole eden küçük testçiler de yapıyorum. API'larda vb. Yaptığım değişikliklerden eminim. Her zaman bunların hala çalıştığından eminim. Bir sonraki projenizde işlevselliği yeniden kullanmak çok daha kolay.

— Iain

Evet, güzel cevap ve bağlantıyı beğendim. Son satıra kadar her şeyi kabul ettim, "Hiç kimse birim testlerin otomatikleştirilmesi gerektiğini söylemedi". :) Var , belki değil - ama her şey ettik okuma anlamına gelir (veya düpedüz diyor) birim testleri gerektiğini otomatik hale yalnızca testlerin hepsi çalıştırmak için tek bir düğmeye basmak noktaya. Aksi takdirde, testleri yürütme konusunda ne kadar çok iş varsa, bunları yeterince sık çalıştırma olasılığınız o kadar az olur. Bahsettiğin eğer Verilen ekran kodu bile mümkünse, bu, birim testi çok daha zor olabilir.

— Cyclops

Yaklaşık dört yıl geçti ve "görsel birim testi" nin neden bu kadar iyi çalıştığını daha iyi anladığımı hissediyorum : Birim testleri bir geliştirme aracıdır. Tipik bir otomatik birim testi size bir şeyin bozuk olduğunu söyleyebilir . Ancak görsel birim testi, çok karmaşık algoritmaları keşfetmenize ve bir şeyin neden kırıldığını hızlı bir şekilde tanımlamanıza yardımcı olabilir (özellikle canlı kod düzenleme ile birleştirildiğinde). Genellikle görsel bir test, aksi takdirde kodla test etmeyi beklemeniz gereken sorunları veya "doğru" yanıtın bulunmadığı sorunları (ör. Ayarlama) belirleyebilir.

— Andrew Russell

Ve birim testlerinin "yeterince sık" yapılması gerektiği fikri (her zamanki gibi, otomatik bir şekilde) sahte. Açıkça değişmeyen kodun tekrar test edilmesi gerekmez. Kod zaman olan değiştirilmiş uygun mevcut testleri (görsel, aksi takdirde kod tabanlı ya da) kullanan, hem değişiklik yapma geliştirici Böylece olmalıdır. Açıkçası, otomatik bir testin değerli bir zaman yatırımı olduğu belirli bir risk profiline sahip bir kod vardır. Ancak bu tür senaryolar özellikle oyun geliştirmede nadirdir.

— Andrew Russell