BDD, orta ve büyük ölçekli projeler için ölçeklenebilir mi?

BDD (Behavior Driven Development) hakkında okuduğunuz her Web sitesinde, gereksinimlerinizi tanımlamanın ne kadar açık ve kolay olduğunu gösteren çok basit ve güzel bir örnek bulacaksınız. Ancak bu süreci büyük bir üründe (hesap makinesi örneği değil) uygulamaya çalışmak, işlerin oldukça karmaşık ve okunamaz hale gelebileceğini (veya elde edebileceğini) gösterdi; Özellikle daha sonraki bir zamanda taleplerin değiştirilmesi, bunun için Entegrasyon testlerini düzeltmek için çok fazla çalışma anlamına gelir.

Merak ediyorum, BDD gerçekten buna değer mi? Diğer tekniklerin yapmadığı bir sorunu çözüyor mu?

Ben en iyi kaynaklardan biri düşünüyorum BDD olan Örnek tarafından Şartname kitapta. BDD testlerinin nasıl düzenleneceği ve gereksinimler değiştiğinde çok fazla yeniden çalışmaya neden olmaması için nasıl yazılması gerektiği hakkında çok şey anlatılmaktadır.

Eğer testlerinizde işler karmaşıklaşır veya karmaşık hale gelirse, muhtemelen yanlış bir şey yapıyorsunuz demektir. BDD ve TDD ile aynıdır. İyi testler yazmak zordur ve bunu öğrenmek aylar alır.

BDD'nin odağının konuşmalar olduğunu fark etmenize yardımcı olabilir . BDD gerçekten bazı regresyon testlerini güzel bir yan ürün olarak sağlayan bir analiz aracıdır.

Konuşmada her seviyede senaryo kullandım; Bir sürümün iyi alınmasının muhtemel olup olmadığını görmek için farklı paydaşları belirlemek , bir modül veya sınıfın nasıl davranması gerektiğine karar vermek .

Bunu kolaylaştırmak için önerebileceğim birkaç ipucu ve püf noktası var.

Daha önce hiç yapmadıysanız, değişecek.

Etki alanı veya işletme için yeni olan herhangi bir şey değişebilir. Senaryolardan bahsederken, onları sorgulayarak ve iş "Ah, emin değilim" diyorsa, bu alanda olduğunuzu fark edebilirsiniz . Bu, BDD'yi yapmaya çalışmaktan vazgeçmenin ve daha hızlı geri bildirim almak için işin istediklerini elde etmelerine yardımcı olmak için bir şeyler dağıtmanın iyi bir işaretidir. Fikirler istikrara kavuştuğunda, senaryolar geriye dönük olarak yazılabilir.

Tüm projelerin yeni bir yönleri var, yoksa bunları yapmazsınız.

Daha önce yaptıysanız, sıkıcı.

Yeni, farklılaştırıcı yönlerin yanı sıra , projeler genellikle kendilerine zaten yapılanlara benzeyen bazı metalaştırılmış yönlere sahiptir. Örneğin, yeni bir cep telefonu üretiyor olsaydım, yine de arama yapması gerekirdi. "Telefon görüşmesi yap", tanınmış bir senaryodur, konuşmamız gerekmeyecek. Benzer şekilde, "giriş" veya "kullanıcı kaydı" gibi şeyler sıkıcıdır.

Mümkün olan yerlerde, bunlar için kütüphaneler kullanın ve sonra etraflarına senaryolar yazmak zorunda kalmazsınız. Ayrıca, önce diğer bitleri yapın - önceden giriş yapmış bir kullanıcıya sahip olun ve ne için giriş yaptığını hesaplayın . Bu alanların değişmesi muhtemel değildir, bu nedenle manuel testlerden yine de kurtulabilirsiniz.

Birisi daha önce yapmışsa, senaryolarla konuşmak yardımcı olabilir.

Etki alanına özgü gereksinimlere sahip olduğumuz yerler, biri tarafından nispeten iyi anlaşılan şeyler ve gerçek belirsizliğin sistemin gerçek davranışından ziyade kapsam çevresinde olduğu durumlar arasında bir miktar var .

Senaryolar üzerinden konuşmak, geliştirme ekibinin davranışı keşfetmesine, bir uzmanın bilgisini kullanmasına ve bilinen, değerli davranışın yakalanmasını sağlamasına yardımcı olabilir.

BDD'nin en iyi çalıştığı yer burasıdır. İpucu, en ilginç senaryoları özellik dosyasının en üstüne yazmak (ya da otomatikleştirmiyorsanız wiki) ve çoğaltılmış ya da sonuç olarak anlaşılması kolay olan senaryoları silmek.

Mümkün olan yerlerde, senaryoları uygulamanın nasıl çalıştığına dair örnekler olarak kullanın . Örneğin, doğrulamanın nasıl çalıştığını göstermek istiyorsanız, uygulamanın kullanıcının formu doldurmasına nasıl yardımcı olduğunu gösteren birkaç örnek gösterin. Doğrulamanın, bakımı çok daha kolay ve çalışması daha kolay olan ünite testi kullanarak sıkı olduğunu kontrol edin.

daha fazla okuma

Bununla ilgileniyorsanız, yazabileceğim ve yardımcı olabilecek bazı şeyler var.

BDD büyük

Bu üç alana daha detaylı olarak giren dev'ler için Cynefin

Benim için çok hoş ve açıklamalı olan eğitici slaytlarım ve tüm yığını da kapsar.

Geçen sonbaharda oldukça karmaşık ( etki alanı karmaşıklığı ) bir proje oluşturduk ve dürüstçe söyleyebilirim ki, öndeki çalışmayı BDD'ye koymak projeyi kurtardı. Etki alanı karmaşıklığı ile BDD'nin yararları arasında güçlü bir ilişki gördüm.

Bir şeyi engellememe izin verin: karmaşık iş kurallarını test etmek zordur. Asıl soru, bir değişiklik yaptığınızda tüm çılgın senaryoları denemek ve hatırlamak mı istiyorsunuz, yoksa spesifikliği kırdığınızda size bildirmek için bu güvenlik ağını mı istiyorsunuz? Başlangıç ​​zamanını harca ve tüm senaryoları hazırla, onları bir yere yaz ve en sonunda onlar için tüm testleri yaz.

Ve daha sonra geri döndüğünüzde, bazı şeyleri anlamaya çalışırken, bu test edilebilir özelliğe sahip olmak hayat kurtarıcıdır.

BDD, TDD'ye dayanan bir geliştirme sürecidir (Test Odaklı Gelişme) İşte TDD'nin kişisel deneyimimden elde ettiği artı ve eksileri:

• TDD, kapsamınızın iyi tanımlanmasını sağlar. Bu şekilde, önce test durumlarınızı tasarlarsınız. Böylece yazmanız gereken kod parçası için bir beklenti belirleyin.
• TDD, kodunuzu korumanın bir yoludur. Basit bir işlev yazdığınızı varsayalım ve daha sonra bu aynı işlevde bazı karmaşık anahtarlama koşullarını ekleyin. Yarın, bir başkası bu işlevi değiştirmek istiyorsa, test senaryosuna başvurabilir. İşlevinizi değiştirmek istiyorsa, test vakasını da (çoğu zaman) değiştirmek zorunda kalır. Bu, yazdıklarınızın arkasında bir sebep olduğunu anlamasını sağlar.
• TDD daha hızlı bir yazılım geliştirilmesine izin verir. Kodlama yaparken her birimiz bu sorunla karşılaşırdık. Bir fikirle başlıyoruz. Ve yavaşça izini kaybedersin. Bazı senaryoları ele almak için istenmeyen kod parçaları koyuyoruz. TDD'de beklentileri önceden belirlediniz. Böylece, kendinizi hedeften çok uzaklarda dolaşmanızı engellersiniz.
• TDD, proje çevrimiçi olmadan önce olası hataları yakalamanızı sağlar. Bunun esas olarak yazılı sınavların kalitesi ile ilgisi var.

Eksileri:

• İlk başta, TDD biraz zor olabilir. Birçok insan, gelişmeyi yönlendiren bir test durumu kavramını anlamamaktadır.
• TDD, bazen bakım konusunda büyük çabalara neden olabilir. Bunun istenmeyen veya anlamsız test durumlarıyla ilgisi var.
• TDD bir tutam tuzla alınmalıdır. Hiçbir geliştirici başkası tarafından yazılmış bir sınavda zaman geçirmekten hoşlanmaz. Test cihazının anlamının şifresini çözmek bazen büyük bir baş ağrısına neden olabilir.

900.000'den fazla kod satırı olan bir proje üzerinde çalışıyorum. Ve hala BDD'yi takip ediyorum. Göz önünde bulundurmanız gereken en önemli şey, yalnızca test durumlarından kaynaklanabilecek olası hataların sayısıdır. Çizgiden birkaç yıl sonra, BDD tarafından yemin edeceksiniz!