BDD ve TDD arasındaki ilişki

BDD ve TDD'nin ilişkisi nedir?

Anladığım kadarıyla BDD, TDD'ye iki ana şey ekliyor: testlerin isimlendirilmesi (sağlanması / yapılması gerektiği) ve kabul testleri. BDD tarafından geliştirme sırasında TDD'yi izlemeli miyim? Cevabınız evet ise, TDD birim testlerim aynı şekilde mı yapılmalı / aynı tarzda mı adlandırılmalıdır?

BDD, TDD döngüsü etrafına bir döngü ekler.

Böylece bir davranışla başlıyorsunuz ve bunun testlerinizi yapmasına izin veriyorsunuz, ardından testlerin gelişimi geliştirmesine izin veriyorsunuz. İdeal olarak, BDD bir tür kabul testi ile yürütülür, ancak bu% 100 gerekli değildir. Beklenen davranışı tanımladığınız sürece, sorun değil.

Öyleyse, bir Giriş Sayfası yazdığınızı varsayalım.

Mutlu yolla başla:

Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page

Verilen ve Ne Zaman Ve Sonra O Zaman Ve Sözdizimi davranış odaklı gelişimde yaygındır. Bunun avantajlarından biri, geliştirici olmayanlar tarafından okunması (ve eğitimi ile yazılmış olması) - yani, paydaşlarınız bir görevin başarılı bir şekilde tamamlanması için belirlediğiniz davranışların listesini görebilir ve görüp görmediğini görebilir. Eksik bir ürün piyasaya sürülmeden çok önce beklentileriyle eşleşir.

Yukarıdakilere çok benzeyen Gherkin diye bilinen ve bu davranışlardaki cümlelerin arkasına test kodu yazmanıza izin veren bir betik dili vardır. Her zamanki gelişme çerçeveniz için Gherkin merkezli bir tercüman aramalısınız. Bu, bu cevabın kapsamı dışında.

Neyse, davranışa geri dönelim. Mevcut uygulamanız henüz bunu yapmıyor (öyleyse neden birisi değişiklik istiyor?), Bu nedenle bir test çalıştırıcısı kullanıyorsanız veya yalnızca manuel olarak test ediyorsanız bu testi geçemezsiniz.

Şimdi bu işlevselliği sağlamak için TDD döngüsüne geçme zamanı.

BDD yazıyor olsanız da yazmasanız da, testleriniz ortak bir sözdiziminde adlandırılmalıdır. En yaygın olanlarından biri, tanımladığınız "gerekir" sözdizimidir.

Bir test yazın: ShouldAcceptValidDetails. Ondan memnun kalana kadar Kırmızı-Yeşil-Refaktör döngüsünden geçin. Şimdi davranış testini geçiyor muyuz? Değilse, başka bir test yazın: ShouldRedirectToUserDefaultPage. Kırmızı-Yeşil-Refactor mutlu olana kadar. Durulayın, yıkayın, davranışta belirtilen kriterleri yerine getirene kadar tekrarlayın.

Ve sonra bir sonraki davranışa geçiyoruz.

Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"

Şimdi, önceki davranışınızı iletmek için bunu önemsememeliydiniz. Bu testte bu noktada başarısız olmalısınız. Bu yüzden TDD döngüsüne geri bırakın.

Ve böylece sayfanızı alana kadar.

Bir Ruby geliştiricisi olmasanız bile BDD ve TDD hakkında daha fazla bilgi edinmek için Rspec Kitabını şiddetle tavsiye edin.

Benim anlayışım:

• BDD, davranışı netleştirmek için TDD'nin yeniden markalaşması olarak başladı.
• Davranış ve yürütülebilir özelliklere odaklanmak için daha resmi destek (DSL ve takım oluşturma) sağlar.
• BDD artık TDD'nin bir üst kümesi olarak görülebilir. Bir şeylerin ortaya çıkma gereksinimlerinin daha fazlasını kapsayacak şekilde zaman içerisinde büyümüştür, ancak yine de geliştirme süreci tarafı bunun temel bir parçasıdır.

Bu yüzden TDD'yi ele almak BDD'nin sağ tarafını yaptı. BDD, sürecin amacını netleştirmek için TDD'nin dilinde bir değişiklik olarak başladı. Dan North’un BDD’ye giriş niteliğindeki makalesinde , test yerine kelime davranışına odaklanmanın neden yararlı olduğunu açıklıyor - bu sadece yazılımı doğru yapmadığınızı, aynı zamanda doğru yazılımı oluşturduğunuzu doğrulamaya yardımcı oluyor. Bu her zaman iyi bir TDD yaklaşımının bir parçasıydı, ancak Dan bunu BDD'ye biraz kodladı.

BDD'nin TDD'den biraz daha açık hale getirdiğini veya en azından resmileştirip araç desteği sağladığını düşündüğüm şey, bu iki zamanlı / çift döngü / yakınlaştırma / uzaklaştırma / uzaklaştırma yaklaşımı. Öncelikle özelliğin beklenen davranışını (dış döngü), ardından düşük seviyeli spesifikasyonlarla başa çıkmak için iç döngüye yakınlaştırırsınız.

Gönderen http://www.metesreau.com/ncraft-workshop/

Salatalık ve SpecFlow gibi araçlarla birlikte Kornişon, bu üst düzey özellik özelliklerini yazmanın ve ardından uygulama kodunu çalıştıran koda bağlamanın bir yolunu sunar. Bunun BDD'nin TDD'den farklı hissedebileceği bir yer olduğunu savunuyorum, ancak yine de bazı ek destek ve bir DSL ile aynı şeyi yapıyor. 'Geleneksel' TDD'ye biraz daha yakın, rspec, nspec, spock gibi araçlar kullanıyor. Bunlar 'geleneksel' TDD'de yapacağınız işlemlere biraz daha fazla benziyor ancak davranış odaklı bir dilde.

Gelen Eylemde BDD (tavsiye) John Ferguson Smart tarafından, o da düşük seviyeli özellikleri için Spock gibi bir aracı haline bırakarak, dış seviye çalıştırılabilir özelliklerine de jBehave gibi bir şey ile başlayan bir çift döngü yaklaşımı için savunmaktadır.

BDD, test odaklı kavramı iş paydaşlarına daha da yakınlaştırıyor. Gherkin, işletme tarafından okunabilir olmak üzere tasarlanmıştır ve 'canlı dokümantasyon' fikri, yani uygulanabilir niteliklerinizden otomatik olarak üretilen ilerleme raporları, paydaşlara geri bildirim vermekle ilgilidir.

BDD'nin şimdi daha büyük bir sürecin parçası olarak TDD'yi birleştiren bir şey haline geldiği bir başka bölüm ise, gereksinim ortaya çıkarma bitleri ve parçalarıdır. Özellik Enjeksiyonu, Etki Eşleme ve Gerçek Seçenekler gibi fikirler bu tarafın bir parçasıdır.

Bu konuda kanonik bir cevap için, tekrar Dan North'a gitmek en iyisi olabilir . Ekibiniz tüm geliştiriciler ise, BDD = TDD. Ekibiniz bir dizi paydaşı içeriyorsa, BDD, DPD'nin bir parçası olduğu için XP'ye daha yakındır.

BDD ve TDD'nin ilişkisi nedir?

Onlar aynı şey.

Anladığım kadarıyla BDD, TDD'ye iki ana şey ekliyor: test isimlendirme

Bu gerçekten BDD'nin "kattığı" bir şey değil. TDD'yi öğretmeyi ve anlamayı kolaylaştıran sadece farklı bir kongredir.

BDD'yi yaratan insanların hepsi TDD öğretiyorlardı ve anlaşılması en zor şeyin TDD'nin kesinlikle test yapmakla ilgisi olmadığını fark ettiler. Öğrenciler bu engelleri aşınca, onlar için çok daha kolay oldu. Ancak, pratikte her yerde "test" (ya da "assert" gibi ilgili terminoloji) kelimesi göründüğünde, kendinizi test etmekten çekinmek çok zor . Böylece, bazı kelimeler değiştirdiler.

Ama bu sadece kelimeler! Orada hiçbir TDD ve BDD arasındaki gerçek fark.

ve kabul testleri.

Kabul testleri, BDD'ler kadar TDD'nin bir parçasıdır. Yine: TDD ve BDD arasında bir fark yoktur: TDD doğru yapılır BDD, BDD doğru TDD yapılır.