Davranış Odaklı Geliştirme
- İngilizcesi
- Behavior-Driven Development
- Türkçe karşılığı
- davranış güdümlü geliştirme
- Okunuşu
- biheyvyır drivın divelıpmınt
Günlük kullanımda çoğunlukla İngilizcesi tercih edilir.
Kısaca
Davranış odaklı geliştirme, geliştiricilerin, test uzmanlarının ve iş tarafının otomatik testlere dönüşen sade dilli örneklerde anlaştığı bir pratiktir.
Davranış odaklı geliştirme nedir?
Davranış odaklı geliştirme ya da BDD, ekibin bir özelliğin nasıl davranması gerektiği konusunda, kod yazılmadan önce sade dilde somut örnekler yazarak anlaştığı iş birliğine dayalı bir yazılım geliştirme yoludur. Bu örnekler daha sonra otomatik testlere dönüşür. BDD'yi, test odaklı geliştirmenin bir evrimi olarak 2000'lerin ortasında Dan North tanıttı; odağı testlerden davranışa ve iş ile teknik kişiler arasındaki ortak bir sözcük dağarcığına kaydırdı.
BDD, bir ürün sorumlusunun, bir geliştiricinin ve bir test uzmanının bir kullanıcı hikâyesini örneklere dönüştürdüğü, çoğu zaman Three Amigos oturumu denen bir konuşmayla başlar. Örnekler Given-When-Then biçiminde senaryolar olarak, sıklıkla Gherkin adı verilen yapılandırılmış bir dilde yazılır: Given bir başlangıç bağlamı, When bir eylem gerçekleştiğinde, Then beklenen bir sonuç. Bir BDD aracı her satırı adım tanımı (step definition) adı verilen küçük bir kod parçasına bağlar; böylece senaryolar otomatik kabul testleri olarak çalışır ve aynı zamanda güncel kalan canlı bir belge işlevi görür.
BDD, kimse pişirmeye başlamadan önce bitmiş pastanın fotoğrafı ve nasıl bir tadı olacağı üzerinde anlaşmaya benzer; böylece herkes başarının neye benzediğini bilir. İş ile geliştirme arasındaki bir yanlış anlamanın pahalıya mal olacağı iş kurallarına ve kullanıcıya dönük özelliklere uygundur. Ancak ek yük getirir: geliştirme ekibi dışında kimse senaryoları okumuyorsa sıradan testler daha basit olabilir.
BDD sıklıkla test odaklı geliştirmeyle karıştırılır. TDD, bir geliştiricinin tek tek kod birimleri düzeyindeki kırmızı, yeşil, yeniden düzenleme döngüsüdür; BDD ise özellik düzeyinde çalışır ve konuşmalara ve ortak dile odaklanır. İkisi iyi birleşir: BDD senaryoları bir özelliği dışarıdan tanımlarken TDD içerideki kodu yönlendirir. Testleri Given-When-Then biçiminde yazmak tek başına BDD değildir; pratiğin özü iş birliğidir.
Önemli noktalar
- BDD, özellikleri ekipteki herkesin okuyabileceği somut örnekler olarak tanımlar.
- Senaryolar, çoğunlukla Gherkin ile yazılan Given-When-Then desenini izler.
- Adım tanımları senaryoları otomatik kabul testlerine dönüştürür.
- Özellik düzeyinde çalışır; TDD ise kod düzeyinde çalışır.
- Onu BDD yapan şey sözdizimi değil, iş birliğidir.
Örnek
Feature: Password reset
Scenario: Registered user requests a reset link
Given a registered user with the email "ada@example.com"
When she requests a password reset for "ada@example.com"
Then she receives an email with a reset link
And the link expires after 30 minutes
Scenario: Unknown email address
Given no account exists for "nobody@example.com"
When someone requests a password reset for "nobody@example.com"
Then the page shows the same confirmation message
And no email is sentSık sorulan sorular
BDD ile TDD arasındaki fark nedir?
TDD, koddan önce başarısız bir birim testi yazmaya dayanan bir geliştirici pratiğidir. BDD benzer bir önce-test fikrini özellik düzeyine uygular ve iş tarafının, geliştiricilerin ve test uzmanlarının birlikte yazdığı sade dilli senaryolar kullanır.
Gherkin nedir?
Gherkin, Feature, Scenario, Given, When ve Then gibi anahtar sözcüklerle BDD senaryoları yazmak için kullanılan basit, yapılandırılmış bir dildir. BDD araçları Gherkin dosyalarını okur ve eşleşen adım tanımlarını test olarak çalıştırır.
Given-When-Then ne anlama gelir?
Given başlangıç durumunu, When eylemi ya da olayı, Then ise beklenen sonucu tanımlar. Bu desen her senaryoyu tek bir davranışa odaklı tutar.
Sık karşılaştırılanlar
İlgili sayfalar
- Test Odaklı GeliştirmeTest ve Kalite, s. 31Test odaklı geliştirme, önce başarısız bir test yazdığınız, sonra onu geçirecek kadar kod yazıp ardından tasarımı temizlediğiniz bir kodlama pratiğidir.
- Kabul TestiTest ve Kalite, s. 11Kabul testi, yazılımın kullanıcılarla ya da müşterilerle anlaşılan gereksinimleri karşılayıp karşılamadığını kontrol eder; ekip sürüm kararını buna göre verir.
- Acceptance CriteriaEkipler ve Süreç, s. 1Acceptance criteria, tek bir user story'nin ya da backlog öğesinin Product Owner'ın kabulü için karşılaması gereken, test edilebilir koşullardır.
- User StoryEkipler ve Süreç, s. 29User story, bir özelliğin kullanıcının bakış açısından, kimin neyi neden istediğini açıklayan kısa ve sade bir dille yazılmış tanımıdır.
- Birim TestiTest ve Kalite, s. 4Birim testi, bir fonksiyonun, metodun ya da sınıfın programın geri kalanından yalıtılmış olarak doğru davrandığını doğrulayan küçük ve otomatik bir kontroldür.
- AgileEkipler ve Süreç, s. 3Agile, çalışan yazılımı küçük ve sık parçalar halinde teslim eden ve planları düzenli geri bildirime göre ayarlayan bir yazılım geliştirme yaklaşımıdır.
Bu sayfada bir hata ya da eksik mi gördünüz?Düzeltme önerin