Bu mu? Olabilir. Benim düşüncem, düşük seviyeli kütüphaneler için iyi çalışabilmesine rağmen, genellikle eğlence yazılımlarına çok zayıf bir uyum sağlayacağıdır.
EDIT: İşte benim görüşüme göre bazı gerekçe.
Wikipedia, BDD'yi bir yazılım projesinde geliştiriciler, KG ve teknik olmayan veya ticari katılımcılar arasında işbirliğini teşvik eden bir teknik olarak tanımlıyor . Bu zaten kötü bir fikir gibi görünüyor çünkü oyunlar çoğu yazılımdan farklıdır, çünkü 'teknik olmayan veya iş katılımcısı' için özel bir ihtiyacı karşılamak için araçlar olarak tasarlanmamıştır, ancak eğlendirmek için geniş çapta tasarlanmış uyumlu çalışmalardır. "İstenen yazılım davranışı" üzerinde bir vurgu vardır, ancak oyunlarda teknik seviye dışında nadiren 'istenen yazılım davranışı' vardır. Kodun bu kısmını kontrol etmenin kesinlikle bir değeri vardır, ancak son kullanıcıyla değil, çünkü asla görmeyeceklerdir.
Ancak, insan paydaşlarını atmak ve sadece farklı kod modülleri arasındaki sözleşmeleri uygulamak için BDD'yi kullanmak istediğinizi varsayalım; bu, görebildiğim kadarıyla normal olarak test edilen geliştirmeden çok da farklı değil - Aşağıdaki nedenlerden dolayı oyunlara uygundur.
Testler, beklenmedik olayların meydana gelip gelmediğini kontrol etmek için yararlıdır. Bu, olay güdümlü programlamada iyi çalışır. bir eylemin gerçekleştirildiği yazılım dünyasının çoğu, bir miktar çıktı üretilir ve daha sonra eylemin ve sonucun eşleştiğini doğrularsınız. Bununla birlikte, oyun yazılımı genellikle bir eylemin ayrı bir sonuca değil, dünya devletinde sürekli bir değişime sahip olduğu bir simülasyondur. Gizli oyuncum bir ses çıkarırsa, AI'nin beni avlayıp avlamadığını kontrol etmek isteyebilirim. Böylece, bir gürültü oluşturulduktan sonra AI'nın 'avlanma' durumunda olduğundan emin olmak için bir test oluşturabilirim ve bu harika. Ama avın bile işe yaradığını nasıl bilebilirim? Bunu anında kontrol edemezsiniz - sadece zaman geçtikçe gözlemleyebilirsiniz.
Buna ek olarak, testten önce bir yaklaşım yanlış bir güvenlik duygusu yaratabilir ve insanları kodun gerçekte olduğundan daha iyi olduğuna inandırmaya yönlendirebilir.
def check_dice_roll_in_range():
d = new Dice()
assert(d.roll() between 1 and 6)
class Dice:
def roll():
return 4
Bir test sonucu yanlış bir pozitif verebileceğinden, kodun kendisini kontrol etmek için temel ihtiyaçtan asla kaçamazsınız. Ancak kodun kendisi yeterince kontrol edilirse, test ikincil önem kazanır. Bu yüzden, bence, testler en iyi olaydan sonra hata düzeltmelerini test etmek için kullanılır.
Testte, X ve Y nesneleri birlikte çalıştığında, elde ettiğiniz sonucun beklendiği gibi olduğu konusunda hiçbir fayda olmadığını iddia etmem. Sorun, bunu doğrulamanın en etkili yolunu kullanıp kullanmadığınızdır. Yöntemler, resmi doğrulama, bir kod incelemesi, ilk test yöntemleri, son test yöntemleri, geleneksel KG kara kutu testini veya basitçe kodu beklendiği gibi kullanmayı ve sonuçları gözlemlemeyi içerebilir. Son iki seçenek çoğu zaman şaşırtıcı derecede etkilidir, çünkü sertlikten yoksun gibi görünmesine rağmen, çoğu hata tipik kullanım sırasında bulunur ve doğal bağlamdaki bir hatayı anlamak bazen yapay bir testte anlamaktan daha kolay olabilir kablo ağı. Bunun üzerinde,
Bu nedenle, özetle, test odaklı geliştirmenin yazılım için mutlaka mükemmel bir seçim olmadığını, sadece yazılım kalitesini sağlamak için tek başına testlerin yeterli olmadığını düşünüyorum (ve bunları yazmak için harcanan zaman, bu geliştirici zamanın alternatif kullanımlarıyla karşılaştırılmalıdır), oyunların otomatik test senaryoları için özellikle kötü bir eşleşme olduğunu ve oyunların 'iş değeri' ve 'kabul testi' ni vurgulayan geliştirme yöntemleri için özellikle kötü bir eşleşme olduğunu.
(Umarım bu benim puanlarıma katılmasanız bile daha iyi bir cevaptır.)