Oyunlarda BDD (Davranış Odaklı Geliştirme) kullanılıyor mu?


9

Bir süredir BDD - Behavior Driven Development hakkında okuyorum ve özellikleri koda dönüştürmek gerçekten kolay ve kullanışlı buluyorum. BDD kullanıcıları genellikle TDD'nin doğru olduğunu söyler.

BDD, dışarıdan içeriye, iş değerinden (veya oyun değerinden) koda kadar yazılım tasarımı için bir araçtır.

Dan North BDD'yi tanıtıyor

Eğer başka BDD ve Oyunlar hakkında tüm kaynakları biliyor musunuz bu ?


Tıpkı TDD'nin bir uyarlaması gibi görünüyor ve bu bağlantı hemen hemen bir kopya.
Komünist Ördek

BDD, TDD yapmak için iyi organize edilmiş bir süreç olduğundan, birisinin kullanıp kullanmadığını ve deneyimin ne olduğunu bilmek istiyorum.
MarcoTmp

Bu soru sorularınızı cevaplamıyor mu?
Komünist Ördek

Gerçekten değil, çünkü hala başkalarının BDD'yi oyunlarda nasıl kullandığını bilmiyorum.
MarcoTmp

Hala TDD'nin farklı bir tarzda icra edildiğini hissediyorum.
Komünist Ördek

Yanıtlar:


14

Muhtemelen TDD gibi BDD'nin veya (modaya uygun geliştirme terimleri kelimesini buraya ekleyin) bazı oyun geliştiricileri tarafından bir yerde kullanıldığını söylemek güvenlidir, ancak muhtemelen ne olduklarını bilmiyorlar ve BDD'nin gerçekte ne anlama geldiğini tanımlayamazlar . Sorusu gerçekten ne kadar onlar bunu kullanmak ve ne kadar do var Sizin için önemli bunun için kullanmak?

Örneğin, çalıştığım yerde, tüm birim test isimlerimiz, Dan North'ın bağlantılandırdığınız makalede önerdiği gibi "cümlelerdir". Tabii ki bu BDD kullandığımızı söylemek için yeterli değil, ama belki de gerçekten önemsediğiniz şey budur?

Bence, bir stüdyoda hangi tereddüt uyguladığınız değil, genel olarak hangi üretkenlik ve geliştirme süreci tekniklerini kullandığınız üzerinde durulmalıdır. En verimli ekiplerin, bazı internet çalışmalarının belirli bir buzzword-paradigmasını içerdiğini söyleyerek, dogmatik olarak taahhüt etmek yerine çeşitli "buzzword-paradigmalar" dan teknikler karıştırıp eşleştirdiklerini görüyorum.

Bunu en çok Agile trendiyle görüyorum: kendilerini “Agile yapmak” olarak tanımlayan takımlar, süreç hakkında, onlar için anlamlı olan Agile parçalarını organik olarak birleştiren takımlardan daha esnek (ironik olarak) olma eğilimindedir. Eski takımlar deneyimlerime göre neredeyse her zaman daha az üretken oluyorlar.

Bir geliştirme ekibi, bir makinede değiştirilebilir dişliler olmayan insanlardan oluşur. Bireysel olarak ve kendilerinin eşsiz bir kombinasyonu olarak çalışırlar. Etkili geliştirmenin yolu, insanlarınızı {BDD, Agile, WhateverIsNext} kalıbına bükmek değil, ekibin süreçteki ilerlemeleri ve ilerlemeleri, kırık tekniklerin yerini alması ve Çalışma. Kısacası, "Agile (ya da ne olursa olsun) değil, bir başlık göndermeye odaklanmak.


Tabii ki burada sahip olduğum tek şeyin dogma sürecine kesin olarak bağlı kalmak ile üretkenlik arasındaki bağlantı hakkındaki yorumlarım için anekdot niteliğindeki kanıtlar olduğuna dikkat etmeliyim. Bu sadece benim deneyimim, bilimsel çalışma değil.

1
-1. Fikrin için teşekkürler. Soruyu cevaplamak ister misiniz?
Jess Telford

+1, güzel cevap. @JoshPetrie En azından bazen TDD kullanıyor musunuz yoksa test kapsamını ölçüyor musunuz? Sadece oyun geliştirici geliştirici test durumu ilginç.
Ilya Ivanov

1

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.)


Benden -1; bir şey varsa, BDD oyunlar için diğer şeylerden daha iyi bir seçimdir. Girişe yanıt olarak bir karakterin davranışını belirtmek, belirli bir XML iletisine yanıt olarak bir web hizmetinin davranışını belirtmekten daha doğaldır .
BlueRaja - Danny Pflughoeft

1
Eğlence yazılımı hala yazılımdır, değil mi?
prusswan

Uzmanlardan gelen çok çeşitli görüşler son derece değerlidir, IMHO. Her insanın cevaplarında bir rep rozeti vardır, bu nedenle okuyucular, belirli bir soru için gönderilen geri kalanlarla birlikte alındığında fikirlerin ne kadar ağır tartılacağını belirleyebilir.
Nate

1
-1'imin yanında duruyorum ve söylenen bazı şeylere cevap vermek istiyorum: collaboration between developers, QA and [users] [...] sounds like a bad idea - games rarely have 'desired software behaviour'- evet öyle: eğlenceli olmalılar. Oyununuzun eğlenceli olup olmadığını bilmenin en iyi yolu, oyuncuları dinlemektir. Geliştiriciler genellikle oyunlarının eğlenceli olmadığı gerçeğine (veya teknik zorluklarla) körleştirilirler. Geliştirici olmayan oyuncuların bu sorunları yok.
BlueRaja - Danny Pflughoeft

2
Testlere gelince: eğer testleri bu şekilde yazıyorsanız, o zaman tamamen yanlış yapıyorsunuz . Ör. sınamak Diceiçin sahte bir Rastgele nesne geçirirsiniz Roll()ve doğru değerleri döndürdüğünüzden emin olursunuz . Normal uygulamaları test etmek için yaptığınız simülasyonları (video oyunları) test etmek için tamamen aynı teknikleri kullanırsınız. Ünite testleri sadece üniteleri test edebilir - bu nedenle "tek başına testlerin yazılım kalitesini sağlamak için asla yeterli olmadığı" (bu yüzden KG hala mevcut). Ancak bu, video oyunları için daha az kullanışlı oldukları anlamına gelmez.
BlueRaja - Danny Pflughoeft

1

BDD'nin her ortamda uygun olduğunu düşünüyorum. Diğerlerinin de belirttiği gibi, yazılım geliştiriyorsunuz ve sonuç olarak test etmeniz gerekiyor. Test isimleri gibi cümle anlamlarından bazıları için bdd'yi cümle olarak seviyorum. Ayrıca, yine de 1 sınıfı test ederken bazı testleri birlikte gruplamayı seviyorum.

Burada diğer mesajlarla mücadele etmek için, daha büyük bir projede, testler olmadan kodu yeniden düzenlemek çok daha zor olduğunu belirtmek isterim. Eğer bazı kodları elden geçirirseniz, her şeyin bir zafer ışığında patlayıp patlamayacağı konusunda kör uçuyorsunuz. Testler, işleri erken yakalamanıza yardımcı olur. Böylece testinizi yazın, başarısız olun, sadece geçip devam etmek için kodlayın. Refactor zaman aynı şeyi yapmak gerekir, ama yazmak yerine testi revize. Çoğu durumda başarısız olacağına dair testi çalıştırırsanız, değişmesi gerektiğini düşündüğünüz şeyi değiştirirsiniz ve STILL başarısız olur. Bu noktada, başka bir kod parçasının bu işleve / yönteme tamamen farklı bir şekilde bağlı olduğunu fark edersiniz. Daha sonra testinizi ve sonuçtaki kodu düzeltebilirsiniz. Bu tür bir kod kapsamı olmadan, öğelerin nerede bozulduğunu bulmaya çalışırken günlerce tökezlersiniz,

Pragmatic Progammer'ın kitabında "Sözleşmeler" konusunu okuyun. Test, kod sözleşmeleri yapmanıza yardımcı olur. Bu kod X ve X'ten başka bir şey yapmaz ve Y hakkında bir şey yapmasını beklemez veya Z yapmak için uyarlamaya çalışmaz. Kod temizliği sağlar ve herkesin bir dick olmamasını ve kod tabanını çamurlamasını bekler.

BDD için daha fazla neden var. Benim için asıl, varsayımlarımı doğrulamak için aynı miktarda test yapacağım, böylece resmileştirebilirim.

"Nasıl" noktasında gerçekten ortamınıza bağlıdır. Şimdi bir java oyunu yazıyorum ve robolektrik kullanıyorum. Her zaman bir şeyler "beklemeye" çalışmalısınız. Casusların / alayların / saplamaların diğer tarafta eşdeğer olması gerektiğinden yararlı olmadığını duydum, ancak bazen özellikle API'lerle seçeneğiniz yok. API'nın diğer tarafının korkunç olmadığını ve genellikle kodunuzun berbat olduğunu varsayabilirsiniz.

Örneğin hareketi test ediyorsanız. "Yukarı" ya basıldığında kullanıcının bir ölçümle ilerlemesini beklersiniz.

Örneğin, grafik oluşturmayı test ediyorsanız ... bunu çok fazla test etmeyin, çünkü bunu gerçekten yapıyorsunuz? İyi bir test çerçevesi bu kısmı sizin için halledebilir. Yansıma, bu tür şeyler için söyleyeceğim çok önemsiz değil. Tamponlar vb. Kontrol etmeniz gerekebilir. Sadece gerçekten ne yaptığınızı kontrol ederdim. Karakter burada, şimdi bir eylemden sonra orada.

Çok sayıda küçük küçük fonksiyona / teste sahip olmalısınız ve birlikte faydalı bir şeyi özetleyeceklerdir.


Son olarak, oyunları / grafikleri kodlarken doğru davranışı elde eden birçok insanı fark ettim. Test etmek "sadece biraz işe yarıyor" etkisini önler. Denklemlerinizin bazı kodları kopyalayıp varsayımlar yapmaktan başka şeyleri nasıl etkileyeceğini bilmek çok daha zordur.
Parris

BDD sadece test etmekle kalmaz, aynı zamanda bunun ötesine geçer.
Daniel

0

BDD'nin ne olduğu hakkında bir yanlış anlama olduğunu hissediyorum. BDD bir TEST tekniği veya süreci değildir. BDD bir geliştirme modeli ve sürecidir. Testin ötesine geçer ve programlamanın ötesine geçer.

Bu nedenle, bu modelle çalışan büyük bir AAA stüdyosu bilmiyorum (dünya çapında bazıları için programcı olarak çalışan arkadaşlarım var). Başka birinin işaret ettiği gibi, bir yerdeki bazı proje yöneticisi veya ekibi BDD'nin kapsadığı bazı uygulamaları içeriyor olabilir, ancak saf BDD uygulayan herhangi bir stüdyo bilmiyorum (iş değeri tanımından örnek belirlemeye kadar) özellik dosyaları, hissedarlarla doğrulamak, özellik dosyalarını test olarak otomatikleştirmek için).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.