TDD ve BDD arasındaki temel farklar nelerdir? [kapalı]


129

Test Güdümlü Geliştirme, son birkaç yıldır .NET topluluğundaki öfke olmuştur. Son zamanlarda, ALT.NET topluluğunda BDD ile ilgili homurdanmalar duydum. Bu ne? Onu TDD'den farklı kılan nedir?


2
Ayrıca programmers.stackexchange.com/q/135218/76176 konusuna bakın . Bu soru daha çok konuyla ilgili.
Evan Carroll

TDD, mikro testler içindir. BDD, gereksinimler veya makro testleri içindir. Test Piramidi ile ilgili 1'den 8'e kadar olan bölümleri dinleyin ve bu seviyeleri açıklayacaktır: agilenoir.biz/series/agile- Thinkts
Lance Kind

Yanıtlar:


104

BDD'nin testten çok spesifikasyonla ilgili olduğunu anlıyorum . Etki Alanı Odaklı Tasarım ile bağlantılıdır (bu * DD kısaltmalarını sevmiyor musunuz?).

Üst düzey testler de dahil olmak üzere kullanıcı hikayeleri yazmanın belirli bir yolu ile bağlantılıdır. Tom ten Thij'den bir örnek :

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Scenario: User uses wrong password

  Given a username 'jdoe'
  And a password 'letmein'

  When the user logs in with username and password

  Then the login form should be shown again

(Makalesinde Tom, bu test özelliğini Ruby'de doğrudan yürütmeye devam ediyor.)

BDD'nin papası Dan North'tur . BDD'ye Giriş makalesinde harika bir giriş bulacaksınız .

Bu videoda BDD ve TDD'nin bir karşılaştırmasını bulacaksınız . Ayrıca Jeremy D. Miller'ın "TDD doğru yapıldı" olarak BDD hakkında bir görüş

25 Mart 2013 güncelleştirmesi

Yukarıdaki video bir süredir eksik. İşte Llewellyn Falco, BDD'ye karşı TDD (açıklandı) tarafından yapılan son bir örnek . Açıklamasını net ve isabetli buluyorum.


10
Video bağlantısı kötü gitmiş gibi görünüyor
James Nail

1
Christian, videonun başlığı ve konuşmacının adı neydi? böylece izini
sürebiliriz

1
'Tom Ten Thij' bağlantısının yukarısında şimdiye kadar kesildi .. işte canlı @ - tomtenthij.nl/2008/1/25/…
Kundan Pandit


16

Bana göre BDD ve TDD arasındaki temel fark odaklanma ve ifade etmektir. Ve niyetinizi iletmek için kelimeler önemlidir.

TDD, odaklanmayı teste yönlendirir. Ve "eski şelale dünyasında" testler uygulamadan sonra geldiğinden, bu zihniyet yanlış anlayış ve davranışa yol açar.

BDD, odaklamayı davranışa ve spesifikasyona yönlendirir ve böylece şelale zihinleri dikkati dağılır. Dolayısıyla BDD, test uygulaması olarak değil, tasarım uygulaması olarak daha kolay anlaşılır.


2
TDD'nin "şelale" yazılım tasarım yaşam döngüsü ile ilgisi yoktur. TDD, SDLC'den bağımsızdır. TDD'nin amacı, bir testi geçmek için gereken minimum miktarda kod yazmaktır. Bir bakıma test, koda uyulması gereken teknik şartname haline gelir.
Gavin Baumanis

1
TDD "Önce Test" dir ve Agile ile oldukça iyi çalışabilir. Bu doğru değil.
Terrance

13

İki tür BDD var gibi görünüyor.

İlki, Dan North'un tartıştığı ve xBehave tarzı çerçevelerin oluşturulmasına neden olan orijinal stildir. Bana göre bu tarz, öncelikle kabul testi veya etki alanı nesnelerine yönelik spesifikasyonlar için geçerlidir.

İkinci tarz, Dave Astels'in popüler hale getirdiği ve bana göre ciddi faydaları olan yeni bir TDD biçimi olan stildir. Testten ziyade davranışa ve ayrıca küçük test sınıflarına odaklanır ve temelde her spesifikasyon (test) yöntemi için bir satıra sahip olduğunuz noktaya ulaşmaya çalışır. Bu stil, tüm test düzeylerine uygundur ve mevcut herhangi bir birim testi çerçevesi kullanılarak yapılabilir, ancak daha yeni çerçeveler (xSpec stili) test etmek yerine davranışa odaklanmaya yardımcı olur.

Yararlı bulabileceğiniz bir BDD grubu da vardır:

http://groups.google.com/group/behaviordrivendevelopment/


7

Test Güdümlü Geliştirme , test odaklı bir yazılım geliştirme metodolojisidir, yani test edilecek gerçek kodu yazmadan önce test kodu yazmayı gerektirir. Kent Beck'in sözleriyle:

Buradaki stil, birkaç satır kod yazmak, ardından çalışması gereken bir test yazmak, hatta daha iyisi, çalışmayacak bir test yazmak ve ardından onu çalıştıracak kodu yazmaktır.

Küçük bir kod parçasının nasıl yazılacağını anladıktan sonra, şimdi sadece kodlama yapmak yerine, anında geri bildirim almak ve "biraz kodlayın, biraz test edin, biraz kodlayın, biraz test edin" alıştırması yapmak istiyoruz. Bu yüzden hemen bunun için bir test yazıyoruz.

Dolayısıyla TDD, programcıların çalışan temiz kod üretmek için kullandıkları düşük seviyeli, teknik bir metodolojidir.

Davranış Odaklı Geliştirme , TDD'ye dayalı olarak oluşturulan, ancak yalnızca programcıları ve testçileri ilgilendirmeyen, bunun yerine tüm ekibi ve teknik ve teknik olmayan tüm önemli paydaşları ilgilendiren bir sürece dönüşen bir metodolojidir. BDD, TDD'nin iyi yanıtlamadığı birkaç basit soruyla başladı: Ne kadar test yazmalıyım? Gerçekte neyi test etmeliyim ve neyi denememeliyim? Yazdığım testlerden hangisi aslında iş için veya ürünün genel kalitesi için önemli olacak ve hangileri benim aşırı mühendisliğim?

Gördüğünüz gibi, bu tür sorular teknoloji ve iş dünyası arasında işbirliği gerektirir. İş paydaşları ve etki alanı uzmanları, mühendislere, kulağa ne tür testlerin faydalı olacağını söyleyebiliyorlar, ancak yalnızca testler önemli iş yönlerini ele alan üst düzey testlerse. BDD, "bu özelliğin nasıl doğru davranması gerektiğine dair bir örnek söyle" gibi iş benzeri testleri "örnekler" olarak adlandırır ve veri doğrulama veya API entegrasyonlarını test etme gibi düşük seviyeli teknik kontroller için "test" kelimesini saklı tutar. Önemli olan, testler yalnızca programcılar ve test uzmanları tarafından oluşturulabilirken, örneklerin tasarımcılar, analistler vb. Tarafından tüm teslim ekibi tarafından toplanıp analiz edilebilmesidir.

Bir cümlede, şu ana kadar bulduğum en iyi BDD tanımlarından biri, BDD'nin "alan uzmanlarıyla sohbet etmek ve istenen davranışı ortak bir şekilde anlamak ve bilinmeyenleri keşfetmek için örnekler kullanmak" ile ilgili olmasıdır. Keşif kısmı çok önemli. Teslimat ekibi daha fazla örnek topladıkça, iş alanını giderek daha fazla anlamaya başlarlar ve böylece uğraşmak zorunda oldukları ürünün bazı yönleri hakkındaki belirsizliklerini azaltırlar. Belirsizlik azaldıkça, teslimat ekibinin yaratıcılığı ve özerkliği artar. Örneğin, artık teknoloji uzmanlığı eksiklikleri nedeniyle işletme kullanıcılarının mümkün olmadığını düşündükleri kendi örneklerini önermeye başlayabilirler.

Şimdi, işletme ve alan uzmanlarıyla görüşmek kulağa harika geliyor, ancak hepimiz bunun ne kadar sıklıkla pratikte sonuçlandığını biliyoruz. Yolculuğuma bir programcı olarak teknoloji ile başladım. Programcılar olarak bize kod yazmamız öğretilir - algoritmalar, tasarım kalıpları, soyutlamalar. Veya tasarımcıysanız, tasarım yapmanız öğretilir.- bilgileri düzenleyin ve güzel arayüzler oluşturun. Ancak giriş seviyesi işlerimizi aldığımızda, işverenlerimiz bizden "müşterilere değer sunmamızı" bekliyorlar. Ve bu müşteriler arasında örneğin ... bir banka olabilir. Ancak bankacılık hakkında hesap bakiyemi verimli bir şekilde nasıl azaltacağım dışında hiçbir şey bilmiyordum. Bu yüzden, benden bekleneni bir şekilde koda çevirmem gerekecekti ... Herhangi bir değer sunmak istiyorsam, bankacılık ile teknik uzmanlığım arasında bir köprü kurmam gerekecek. BDD, teslimat ekibi ile alan uzmanları arasında istikrarlı bir akışkan iletişim temeli üzerinde böyle bir köprü kurmama yardımcı oluyor.

Daha fazla bilgi edin

BDD hakkında daha fazla okumak isterseniz konuyla ilgili bir kitap yazdım. "Harika Spesifikasyonlar Yazmak" , gereksinimleri analiz etme sanatını keşfeder ve harika bir BDD sürecini nasıl oluşturacağınızı öğrenmenize ve bu sürecin temel bir parçası olarak örnekleri kullanmanıza yardımcı olur. Kitap, her yerde bulunan dilden, örnekler topladığından ve örneklerden sözde çalıştırılabilir spesifikasyonlar (otomatik testler) yaratmasından bahsediyor - BDD ekiplerinin zamanında ve bütçeye uygun harika yazılımlar sunmasına yardımcı olan teknikler.

"Harika Özellikler Yazmak" satın almakla ilgileniyorsanız, 39nicieja2 promosyon kodu ile % 39 tasarruf edebilirsiniz :)


6

BDD yaklaşımını biraz denedim ve erken sonucum, BDD'nin vaka uygulamasını kullanmak için çok uygun olduğu, ancak temeldeki ayrıntılarda olmadığıdır. TDD hala bu seviyede sallanıyor.

BDD ayrıca bir iletişim aracı olarak kullanılır. Amaç, alan uzmanları tarafından anlaşılabilecek çalıştırılabilir özellikler yazmaktır.


2

Bana öyle geliyor ki BDD daha geniş bir kapsam. Neredeyse TDD'nin kullanıldığını, BDD'nin hızlı geri bildirim sağlamak için diğer şeylerin yanı sıra TDD uygulamalarını kullanmak için bilgi ve gereksinimleri toplayan kapsayıcı bir metodoloji olduğunu ima eder.


2

TDD ile karşılaştırıldığında BDD'deki en son bilgimle BDD, daha sonra ne olacağını belirlemeye odaklanırken, TDD bir dizi koşul oluşturmaya ve ardından çıktıya bakmaya odaklanır.


2

Davranış Odaklı Geliştirme, Geliştiriciler arasındaki ve ayrıca Geliştiriciler ile test ediciler arasındaki etkileşime ve iletişime odaklanıyor gibi görünüyor.

Wikipedia Makalesinin bir açıklaması var:

Davranış odaklı geliştirme

BDD'yi kendim yapmıyorum.


2

TDD'nin birincil faydasının tasarım olduğunu düşünün. Teste Dayalı Tasarım olarak adlandırılmalıdır. BDD, TDD'nin bir alt kümesidir, buna Davranış Odaklı Tasarım deyin.

Şimdi TDD - Unit Testing'in popüler bir uygulamasını düşünün. Birim Testindeki Birimler, tipik olarak yapabileceğiniz en küçük iş birimi olan bir bit mantıktır.

Makinelere istenen Davranışı açıklamak için bu Birimleri işlevsel bir şekilde bir araya getirdiğinizde, makineye tanımladığınız Davranışı anlamanız gerekir. Davranış Odaklı Tasarım, uygulayıcıların Kullanım Örnekleri / Gereksinimler / Her ne olursa olsun anlayışını doğrulamaya odaklanır ve her özelliğin uygulanmasını doğrular. Genel olarak BDD ve TDD, tasarımın bilgilendirilmesi için önemli bir amaca ve özellikle değiştiğinde uygulamanın doğruluğunun doğrulanması ikinci amacına hizmet eder. Doğru yapılan BDD, biz ve dev'i (ve qa) içerirken, Birim Testi (muhtemelen yanlış bir şekilde bir TDD türü yerine TDD olarak görülür) genellikle geliştirici silosunda yapılır.

BDD testlerinin yaşam gereksinimleri olarak hizmet ettiğini eklemek isterim.



1

TDD ve BDD arasında hiçbir fark yoktur. dışında testlerinizi daha iyi okuyabilir ve gereklilik olarak kullanabilirsiniz. Gereksinimlerinizi BDD testlerini yazarken aynı sözcüklerle yazarsanız, o zaman kod yazmaya hazır tanımlanmış bazı testlerinizle müşterinizden gelebilirsiniz.


1

Test odaklı geliştirme (TDD) ve davranış odaklı geliştirme (BDD) arasındaki fark

  • BDD, TDD'nin odaklandığı sistemin
    uygulama yönünden ziyade sistemin davranışsal yönüne odaklanır.

  • BDD
    , geliştirici ve müşteri açısından sistemin ne yapması gerektiği konusunda daha net bir anlayış sağlar . TDD, yalnızca
    geliştiriciye sistemin ne yapması gerektiğine dair bir anlayış verir.

  • BDD, hem geliştiricinin hem de müşterinin, sistemin kaynak kodunda bulunan gereksinim analizi üzerinde birlikte çalışmasına olanak tanır.


1

Kısacası, TDD ve BDD arasında büyük bir fark var TDD'de büyük ölçüde Test verilerine odaklandık BDD'de ana odak noktamız projenin davranışına odaklanır, böylece programlamayan herhangi bir kişi, başlık adına kod satırını anlayabilir. o yöntem


1

İşte hızlı anlık görüntü:

  • TDD sadece kodu yazmadan önce test etme sürecidir!

  • DDD, her kod dokunma döngüsünden önce Domain hakkında bilgilendirilme sürecidir!

  • BDD, DDD'nin bazı yönlerini getiren bir TDD uygulamasıdır!

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.