BDD - BDD Yolunda TDD
TDD'de "Kabul Testleri" terimi yanıltıcıdır. Kabul testleri aslında sistemin beklenen davranışını temsil eder. Çevik uygulamalarda, tüm ekibin iş birliği ve müşteri ve diğer paydaşlarla etkileşime vurgu yapılır. Bu, projeye dahil olan herkes tarafından kolayca anlaşılabilen terimlerin kullanılması gerekliliğini doğurmuştur.
TDD gerekli olanları düşünmenizi sağlar Behavior ve bu nedenle 'Davranış' terimi, ‘Test’. BDD, testlere değil davranışa odaklanan bir kelime dağarcığı içeren Test Odaklı Geliştirmedir.
Dan North'un sözleriyle, "Testlerde düşünmekten davranışta düşünmeye geçişi o kadar derin buldum ki, TDD'den BDD veya Davranış Odaklı Geliştirme olarak bahsetmeye başladım." TDD bir şeyin nasıl çalışacağına odaklanır, BDD onu neden inşa ettiğimize odaklanır.
BDD, geliştiricilerin sıklıkla karşılaştığı şu soruları yanıtlıyor:
| Soru | Cevap |
|---|---|
| Nereden başlamalı? | dıştan içe |
| Ne test edilmeli? | Kullanıcı hikayeleri |
| Neyi test etmemek? | başka herhangi bir şey |
Bu cevaplar, aşağıdaki gibi hikaye çerçevesinde sonuçlanır -
Story Framework
Olarak [Role]
İstiyorum [Feature]
Böylece [Benefit]
Bu, ' Feature yürütülür, sonuç Benefit oynayan kişiye Role.'
BDD aşağıdaki soruları da yanıtlıyor -
| Soru | Cevap |
|---|---|
| Tek seferde test etmek ne kadar? | çok az odaklanmış |
| Testlerine ne denir? | cümle şablonu |
| Bir testin neden başarısız olduğu nasıl anlaşılır? | dokümantasyon |
Bu cevaplar, aşağıdaki gibi Örnek çerçevesinde sonuçlanır -
Example Framework
Given başlangıç bağlamı,
When bir olay meydana gelir,
Then bazı sonuçların sağlanması.
Bu, 'İlk bağlamdan başlayarak, belirli bir olay meydana geldiğinde, sonuçların ne olduğunu biliyoruz. should be. '
Bu nedenle, örnek sistemin beklenen davranışını göstermektedir. Örnekler, sistemin farklı senaryolarını göstermek için kullanılır.
Hikaye ve Senaryolar
Bir ATM sistemi ile ilgili olarak Dan North tarafından yapılan aşağıdaki resme bakalım.
Hikaye
As a müşteri,
I want ATM'den nakit çekmek için,
so that Bankada sıra beklememe gerek yok.
Senaryolar
Bu hikaye için iki olası senaryo var.
Scenario 1 - Hesap kredili
Given hesabın kredisi var
And kart geçerlidir
And dağıtıcı nakit içeriyor
When müşteri nakit istiyor
Then hesabın borçlandırıldığından emin olun
And Nakit dağıtıldığından emin olmak
And kartın iade edildiğinden emin olun
Scenario 2 - Hesap, limit aşımına uğradı
Given hesap fazla çekilmiş
And kart geçerlidir
When müşteri nakit istiyor
Then bir ret mesajının görüntülenmesini sağlayın
And Nakit dağıtılmamasını sağlamak
And kartın iade edildiğinden emin olun
Olay her iki senaryoda da aynıdır, ancak bağlam farklıdır. Dolayısıyla sonuçlar farklıdır.
Geliştirme Döngüsü
BDD için Geliştirme Döngüsü bir outside-in yaklaşmak.
Step 1- Kırmızıya dönüşen üst düzey (dış) bir iş değeri örneği (Salatalık veya RSpec / Kapibara kullanarak) yazın. (RSpec, Ruby dilinde bir BDD çerçevesi oluşturur)
Step 2 - Kırmızı olan uygulamanın ilk adımı için daha düşük seviyeli (içeriden) bir RSpec örneği yazın.
Step 3 - Bu alt düzey örneği geçmek için minimum kodu uygulayın, yeşile döndüğünü görün.
Step 4 - Kırmızı olan Adım 1'i geçmeye doğru ilerleyen bir sonraki alt seviye RSpec örneğini yazın.
Step 5 - Adım 1'deki üst düzey örnek yeşil olana kadar Adım 3 ve Adım 4'ü tekrarlayın.
Note - Aşağıdaki noktalar akılda tutulmalıdır -
Red/green durum bir izin durumudur.
Düşük seviyeli testleriniz yeşil olduğunda, yeni örnekler yazma veya mevcut uygulamayı yeniden düzenleme iznine sahip olursunuz. Yeniden düzenleme bağlamında yeni işlevsellik / esneklik eklememelisiniz.
Düşük seviyeli testleriniz kırmızı olduğunda, yalnızca mevcut testlerin yeşile dönmesi için uygulama kodunu yazma veya değiştirme iznine sahip olursunuz. Var olmayan bir sonraki testinizi geçmek için kodu yazma dürtüsüne direnmelisiniz veya iyi olduğunu düşündüğünüz özellikleri (müşteri istemezdi) uygulamaya koymalısınız.