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?
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?
Yanıtlar:
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.
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.
İ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:
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 :)
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.
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:
BDD'yi kendim yapmıyorum.
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.
BDD, büyük ölçüde TDD'nin doğru yapılmasıdır. Bununla birlikte, BDD'nin sunduğu ek değer vardır. İşte bununla ilgili bir bağlantı:
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.
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
İş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!