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.