Oyunlar için test stratejisi

Web tabanlı bir eğitim oyunu miras aldım. Geçtiğimiz yıl kodu stabilize etmek ve yeni özellikler eklemek için çalıştım. Mantığın çoğu ön uçtadır, bu nedenle arka uç birim testleri yardımcı olsa da kodun küçük bir yüzdesini kapsar.

Oyun karmaşıklaşmaya başladığı noktaya geldi. Her oyun için iki farklı mod vardır ve oyun moda bağlı olarak farklı davranır. Oyun oynamayı etkileyen çeşitli bayraklar da var.

10 yılı aşkın bir süredir uygulama geliştiriciyim ve bu beni şaşırtıyor. Kurumsal dünyada, bir algoritma her zaman aynı şekilde çalışır. Bir algoritma için birim testi yazacağım, 42 değerini bekleyeceğim ve bu değeri alamazsam hata yapacağım.

Oyun söz konusu olduğunda, kayboldum. Onları nasıl test ederim? Benim için test edicilerim var. Birim testleri yazmak için zaman harcayabilirim.

Test ediciler ... güvenilmez. Sorunları köklendirme konusunda en iyisi değiller ve onlara en iyi yönü vermedim. Oyunun her permütasyonunu ve kombinasyonunu test eden her sürüm döngüsünde bir ton zaman harcamadığımda, bunları bir kaynak olarak nasıl kullanmalıyım?

Birim testleri sınırlı görünmektedir. Mantığın çoğu javascript olduğundan (ve spagetti kodunu devraldım), bazı özelliklerin çalıştığından emin olmak için Salatalık veya selenyum gibi bir ön paket kullanabilirim.

Bu en iyi strateji mi? Oyun şirketleri oyunları nasıl test eder?

" Karmaşık Oyunlar için Test Odaklı Geliştirme " (sitedeki diğerleri arasında) sorusunu okudum , ancak aradığım şeyi ele almıyor. Nasıl test edileceğine dair spesifik örnekler değil stratejiler istiyorum.

Kurumsal dünyada, bir algoritma her zaman aynı şekilde çalışır. Bir algoritma için birim testi yazacağım, 42 değerini bekleyeceğim ve bu değeri alamazsam hata yapacağım.

Bu oyunlarda çok farklı değil. Üzerinde çalıştığınız oyunda iki modun ve çoklu bayrakların varlığı hiçbir şeyi değiştirmez: belirli bir bayrak kümesiyle belirli bir modu alırsanız, bir parçasını test ederken yine aynı değeri tekrar alırsınız kaynak kodu.

Çok fazla mod ve bayrakla, olası varyantların sayısı nedeniyle oyunun test edilmesi çok zor olabilir. Bu zorluğa erken girme riskini azaltmak için şunları yapmalısınız:

• Sahte / saplama şiddetli . Test edilen parçaları küçük tutun ve güvendikleri her şeyi alay edin.

  Zamana güveniyorlarsa, gerçek zamandan bağımsız olarak her zaman belirli bir sonuç veya belirli bir sonuç kümesi vermek için time nesnesini alay edin.

  Güveniyorlarsa, random()her seferinde bir sabit sağlamak için alay et.

• Refactor . Testler aşırı derecede karmaşıklaşmaya başlarsa veya bir sınıfın test edilmek için, Bağımlılık Enjeksiyonu uyguladıktan sonra on iki argüman gerektirdiğini görürseniz, sadece iki tane daha gerekiyorsa, kodu yeniden düzenlemeniz gerekir.

• Uygulamanın gerçek iş kurallarını sorgular . Kimsenin ihtiyaç duymadığı veya anlamadığı fonksiyonel gereksinimlerin gerektirdiği farklı varyasyonların sayısı nedeniyle test edilmesi neredeyse imkansız olan proje sayısını saymayı bıraktım - paydaşlar bile.

  Küçük bir e-ticaret web sitesi, gönderi fiyatlarının nasıl hesaplandığını belirlemek için kullanılan fonksiyonel gereksinimleri açıklamak için on sayfaya ihtiyaç duyduğunda, test veya kod yazarak başlamamalı, bunun yerine paydaşlara geri dönmeli ve üretmek için onlarla çalışmalıdır. aklı başında .

Son olarak, her testi otomatikleştirin . Uygulamanın başarısız olduğu durumları keşfetmek için test kullanıcılarına ihtiyaç vardır. Her revizyonda aynı eylemi gerçekleştirmek için test cihazlarını kullanmak, karşı eylemi ve test kullanıcılarına saygısızdır: regresyon testi insanlar tarafından değil makineler tarafından yapılmalıdır. Öte yandan insanlar olası hataları bulma konusunda çok daha iyidir. "Ya ben ..." kullanabilecekleri tekniklerden biridir ("Yaşımı soran bir alana birkaç \ x00 içeren birkaç megabayt ikili veri girersem ve ne olacağını görürsem?"), ancak daha resmi yaklaşımlar da kullanılabilir.