Bir oyun motorunda birim testi nasıl yapılır?

Çok utanç duyduğum kadarıyla, hiçbir zaman uygun bir ünite testi yazmadım, sadece testten sonra başarılı olacağım küçük organize olmayan test programları. Bir oyun projesinde birim testinin nasıl yapılması gerektiği konusunda net bir fikrim yok. (Dilim C ++.)

Motorumdaki her bir alt sistem için ayrı bir projem ve bununla ilişkili bir test yapmalı mıyım ve daha sonra gerçek motoru oluşturan daha büyük bir projeye / çözüme sahip olmalı mıyım? Mesela motorumda eventmodül var ; Bununla nasıl başa çıkmalıyım?

İlk önce, bir birim test çerçevesine ihtiyacınız olacak. Geçmişte UnitTest ++ ve Google Test kullandım . Eski çok hafif ve ikincisi daha özellikli ama biraz daha hantal. Böyle bir şeye ihtiyacın olursa , Google Mock ile iyi bütünleşir . Elbette pek çok başka seçenek var: bu listeye bakın (en son UnitTest ++ yazarı tarafından) ve örneğin Vikipedi .

Birim testi, çeşitli senaryolar altında izole edilmiş bağımsız kod bitlerini ("birimler") vurgulamak için odaklanmış testler yazmakla ilgilidir. Bazı durumlarda her şeyi test edebilirsiniz, ancak% 100 kapsama alanı elde etmek pratik değildir, özellikle oyunlarda oldukça zor olabilir - işleyici çıktınızın birim testini anlamlı, yararlı veya herhangi bir şekilde yapıp yapmamak tartışılabilir. ne olursa olsun bir "gerçek" birim testi.

Herhangi bir (otomatik) testin hiçbir (otomatik) testten daha iyi olmadığını hatırlamak önemlidir. Bu nedenle, testlerinizin “gerçek birim testleri” olmadığı ve sadece testler yaptığınız için gurur duyduğunuz için çok fazla stres yapmamalısınız. Birim test çerçeveleri genellikle daha gevşek, "birim olmayan" testler yapmak için de kullanışlıdır, çünkü paketleme testleri ve hataları düzgün bir şekilde raporlamak için işlevsellik içerirler.

Eski testlerinizi yeniden canlandırmanızı ve bunları mevcut çerçevelerden birini kullanarak bir test projesine dönüştürmenizi öneririm - bunları kolayca çalıştırabileceğiniz (veya otomatik olarak bir sürüm veya entegrasyon yapısının parçası olarak) çalıştırabilir. senin testlerin. Kod bitleri için yeni testler yazın, bunlar sizin için faydalı olacak gibi görünür, örneğin bir testte tespit edebileceğiniz ince bir hata keşfederseniz, gelecekte yapabileceğiniz herhangi bir gerilemeyi yakalamak için bir tane ekleyebilirsiniz.

Muhtemelen oyunlarda, ünite testlerine uygun düşük seviyeli hizmet kodunuz olduğunu göreceksiniz. Sorun değil - kırılırsa daha yüksek katmanlara zarar verebilecek temel koddur.

Kod tabanınızdaki her küçük işlev ve mantıksal geçit için sınama yapamadığınız için programcının arafına girmeyeceksiniz, bu nedenle sınama yazmak için gerekenden daha fazla zaman harcamayın. Bir modülün testlerini yazmak için harcadığınızdan daha fazla düşünmek veya daha fazla zaman harcamak zorunda kalırsanız, ilk etapta bu modülü sizin yazmanız için harcadığınız zaman, zamanınızı boşa harcıyor olabilirsiniz. Birim testi - genel olarak test etme - her şey için yapmanız gereken bir görev değil, size yardımcı olmak için uygun şekilde kullanmayı öğrendiğiniz bir araçtır.

Burada oyun geliştirme için TDD ve birim testi kullanma hakkında çok sayıda blog yazısı var: http://gamesfromwithin.com/stepping-through-the-looking-glass-test-driven-game-development-part-1

Bir "birim", test edilebilir en küçük kod parçasıdır, tipik olarak tek bir fonksiyon veya sınıftır. Birim testi, amaçlandığı şekilde davranmasını sağlamak için bu birim kodunu kullanan başka bir kod parçasıdır. Tek bir kod biriminin tüm durumları kapsayacak şekilde birçok testi olabilir.

Tipik olarak, testler bir projenin ana inşaatına dahil edilmez. Aksine, tüm test kodunu içeren ve tüm testleri çalıştıran ve sonuçları rapor eden bir program üreten test için ayrı bir yapı yapılandırması vardır. Bir test çerçevesi bunun için tüm iskeleleri sağlayacaktır ve kesinlikle gerekli olmasa da önerilir. Testlerde tamamen yeni iseniz, olup biten her şeyi anladığınızdan emin olmak için ilk önce kendi özel test cihazınızı yazarken daha iyi olabilirsiniz.

Testlerde, kendinize güvenmediğiniz kodlara öncelik vermeden veya kırılgan ve gelecekteki değişikliklerle kırılabilecek kodları öncelik sırasına koyabilirsiniz. Testleri sık sık, ideal olarak her kod değişikliğinden sonra yapmalısınız.