BDD kullanırken birim testleri nasıl kullanılır?

BDD'yi anlamaya çalışıyorum. Bazı makaleler okudum ve anladığım kadarıyla BDD, TDD'nin "bir sonraki adımı". Her ikisini de çok benzer bulduğum ve bu makalede okuyabileceğim gibi , BDD'nin TDD'den bir gelişme olarak doğduğunu söylüyorum . Harika, fikri gerçekten seviyorum.

Düşünmediğim pratik bir nokta var: BA'nın sistemin sahip olacağı tüm beklenen davranışları yazacağı bir .feature dosyası var. Bir BA olarak, sistemin nasıl kurulduğuna dair hiçbir fikri yoktur, bu yüzden böyle bir şey yazacağız:

+ Senaryo 1: Hesap kredidir +

Hesabın kredide olduğu göz önüne alındığında

Ve kart geçerli

Ve dağıtıcı nakit içeriyor

Müşteri nakit istediğinde

Sonra hesabın borçlandırıldığından emin olun Ve nakit dağıtımını sağlayın

Ve kartın iade edildiğinden emin olun

Tamam, bu harika, ancak sistemin olabilmesi için işbirliği yapacak birçok bölümü var (Hesap nesnesini, Dağıtıcı nesnesini, Müşteri nesnesini vb. Düşünün). Bana göre bu bir uyum testi gibi görünüyor.

Birim Testleri yaptırmak istiyorum. Vericinin parası olup olmadığını kontrol eden kodu nasıl test edebilirim? Yoksa nakit dağıtılıyor mu? Yoksa hesap gerektiğinde borçlandırılıyor mu? Birim testlerini "BA Created" testleri ile nasıl karıştırabilirim?

Davranış Odaklı Geliştirme ve Test Odaklı Geliştirme ücretsizdir, ancak birbirlerinin yerine geçmez.

Uygulamanın nasıl davrandığı, BDD'ye göre Salatalık'ta yazılan Özellikler ve Senaryolar olacak Kabul Testlerinde açıklanmaktadır.

Her bir küçük bileşenin nasıl çalıştığına dair ayrıntılı cesur ayrıntılar Birim Testlerinde açıklanmaktadır. Birim Testlerinin sonuçları Salatalık'ta yazdığınız Senaryoları destekler.

Bir araba inşa etme sürecini hayal edin.

İlk olarak, ürün ekibi fikirlerini ortaya çıkarır ve sonunda bunları kullanım senaryolarına indirir:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Bu senaryonun biraz aptalca geldiğini biliyorum, ancak çok yüksek düzeyde, ürün ve son kullanıcı odaklı bir gereklilik. Sadece kapıyı açmak, anahtarı döndürmek ve motoru çalıştırmak birlikte çalışan bir çok farklı bileşeni içerir. Bu tek test, aracın düzgün çalıştığından emin olmak için yeterli değildir. Marş motorunu, aküyü, alternatörü, anahtarı, kontak anahtarını - test etmeniz gerekir ve liste devam eder - sadece arabaya girip başlatmak için. Bu bileşenlerin her birinin kendi testlerine ihtiyacı vardır.

Yukarıdaki senaryo bir "Büyük Resim" testidir. Aracın her bileşeninin, genel olarak düzgün çalıştıklarından emin olmak için "Küçük Resim" testlerine ihtiyacı vardır.

Yazılım oluşturma ve test etme birçok açıdan aynıdır. Yukarıdan aşağıya tasarım yaparsınız, sonra aşağıdan yukarıya doğru inşa edersiniz. Motoru bile çalıştıramazsanız neden yukarı açılan bir kapınız var? Piliniz yoksa neden bir marşınız var?

Ürün ekibiniz Kabul Testleri yapacak ve bunları Salatalık'ta tanıtacaktır. Bu size "Büyük Resim" verir. Şimdi uygun bileşenleri ve nasıl etkileştiklerini tasarlamak mühendislik ekibine kalmıştır, daha sonra her birini ayrı ayrı test edin - bunlar Birim Testlerinizdir.

Birim Testleri geçtikten sonra Salatalık senaryolarını uygulamaya başlayın. Bunlar geçtikten sonra, ürün ekibinin istediklerini teslim ettiniz.

BDD'yi anlamaya çalışıyorum. Bazı makaleler okudum ve anladığım kadarıyla BDD, TDD'nin "bir sonraki adımı". Her ikisini de çok benzer bulduğum ve bu makalede okuyabileceğim gibi, BDD'nin TDD'den bir gelişme olarak doğduğunu söylüyorum.

Aslında hayır, BDD TDD'nin "bir sonraki adımı" değil . O ise TDD. Ya da daha doğrusu, TDD'nin bir yeniden ifadesidir.

BDD'nin yaratıcıları, TDD'nin testle ilgili değil, davranışsal spesifikasyonla ilgili olduğunu anlamanın önündeki en büyük engelin, TDD terminolojisinin tümünün davranışsal spesifikasyonla değil testle ilgili olduğunu fark ettiler. Birisi size "pembe bir fil düşünmemeye çalış" dediğinde pembe bir fil düşünmemeye çalışmak gibi, pembe fillerle dolu bir odada olmanın ve sürekli "pembe fil, pembe fil, pembe fil "kulağında.

Bu nedenle, TDD'yi davranışsal şartname açısından yeniden ifade ettiler. "Testler" ve "test senaryoları" artık "örnekler", "birimler", "davranışlar", "iddialar", "beklentiler" ve benzerleridir.

Bununla birlikte, yöntem hala aynıdır. Bir kabul testiyle (yani "özellik") başlar, bir birim testine yakınlaştırırsınız ("örnek" demek istiyorum), uzaklaştırma vb.

Birim Testleri yaptırmak istiyorum. Vericinin parası olup olmadığını kontrol eden kodu nasıl test edebilirim? Yoksa nakit dağıtılıyor mu? Yoksa hesap gerektiğinde borçlandırılıyor mu? Birim testlerini "BA Created" testleri ile nasıl karıştırabilirim?

TDD'de yaptığınız gibi. Özelliklerinizi ve örneklerinizi farklı çerçevelerde (örn. Salatalık ve RSpec) veya hatta farklı dillerde yazabilirsiniz (örneğin C'de bir C projesi için örnekler ve FIT / Fitnesse'deki özellikler), her ikisi için de tek bir özellik çerçevesi kullanabilirsiniz ( örneğin, Salatalık'ta örnek ve özellik yazma) veya her ikisi için de tek örnek çerçeve kullanabilirsiniz (örneğin her ikisini de RSpec'de yazmak). Hiç bir çerçeve kullanmak zorunda değilsiniz.

Sadece tek bir çerçeve kullanan TDD-right-right (BDD ile aynı) örneği, hepsi JUnit'in kendisinde yazılmış olan birim testleri (örnekler) ve fonksiyonel / entegrasyon testleri (özellikler) karışımını içeren JUnit'in kendisidir.

Kent Beck'in buna "yakınlaştırma" dediğine inanıyorum. Yüksek seviyeyi başlatın, ardından ayrıntıları "yakınlaştırın" ve ardından tekrar geri çekin.

Feragatname: BDD'de uzman değilim, ancak bağlantı verdiğiniz makaleye bakış açımı vermeye çalışıyorum.

TDD bir uygulama tekniğidir - önce bir test yazarsınız, daha sonra yöntemi uygularsınız, testinizi çalıştırırsınız, refactor ve aynı yöntem veya yeni bir yöntem için başka testler eklersiniz. TDD aslında sınıf veya yöntem adlarının nasıl seçileceğine dair herhangi bir kural tanımlamaz, bu size bağlıdır. TDD ayrıca size "işiniz bittiğinde" söylemez.

Bu nedenle, yeni bir yöntem için bir test yazdığınızda, bir yöntem adı seçmeniz gerekir - bu da BDD'nin geldiği noktadır. Yukarıdaki senaryodaki iş terimlerini kullanarak yöntem adlarını seçerek ve bunları açıklayan bir şekilde seçerek Sınıfınızın davranışını BDD yapıyorsunuz. Kendinize "daha fazla test eklemem gerekiyor mu?" Diye sorduğunuzda, BA'nız tarafından verilen senaryolara bakabilir ve gerekli tüm parçaları tamamen uygulayıp uygulamadığınızı kontrol edebilirsiniz. Değilse, daha fazla test eklemeniz gerekir.

Makalenin yazarı, testlerinizin adlarını seçerken daha fazla davranışla ilgili bir adlandırma düzeni kullanmanızı önerir, bu nedenle JUnit'in her test vakasının başlaması gereken bir adlandırma düzenine güvenmeyen bir araçla değiştirilmesini önerir. adı "test". JBehave'yi bilmememe rağmen, bu araç ile Junit arasındaki temel fark olduğunu düşünüyorum.

Dahası, BDD senaryoları da , TDD tarafından yöntem adlarını sildikten sonra ve makul miktarda birim testi ekledikten sonra ekleyeceğiniz entegrasyon testleri için bir taslak olacaktır .

Anladığım kadarıyla TDD, BDD'nin bir parçası olarak kullanabileceğiniz bir araçtır ve BDD doğru testleri yazmanıza ve onlara daha iyi adlar vermenize yardımcı olur.