Kokie yra pagrindiniai TDD ir BDD skirtumai?

Per pastaruosius kelerius metus bandomoji plėtra buvo .NET bendruomenės pyktis. Neseniai aš girdėjau, kad ALT.NET bendruomenė griauna apie BDD. Kas tai? Kas tai skiriasi nuo TDD?

117
05 авг. nePasirinkta 05 rugpjūtis 2008-08-05 18:58 '08, 18:58, 2008-08-05 18:58
@ 15 atsakymų

Suprantu BDD daugiau apie specifikacijas nei bandymai . Jis yra susijęs su „Domain Driven Design“ (ar jums nepatinka šios DD santrumpos?).

Jis yra susijęs su konkrečiu vartotojo istorijų rašymo būdu, įskaitant aukšto lygio testus. Pavyzdys Tom ten Thij :

 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 

(Savo straipsnyje Tomas toliau tiesiogiai atlieka šį Ruby testo specifikaciją.)

Tėtis BDD Dan North . Rasite nuostabų įvadą į straipsnį „ Įvadas į BDD“ .

Šiame vaizdo įraše rasite BDD ir TDD palyginimus. Taip pat nuomonė apie BDD kaip "TDD padaryta teisė" iš Jeremy D. Miller

Atnaujinta 2013 m. Kovo 25 d

Vaizdo įrašas anksčiau nebuvo. Čia yra neseniai Llewellyn Falco, BDD vs TDD (paaiškinta) . Manau, kad jo paaiškinimas yra aiškus ir tikslus.

92
05 авг. Atsakymą pateikė Christian Lescuyer 05 rug . 2008-08-05 19:36 '08 at 7:36 pm 2008-08-05 19:36

Man svarbiausias skirtumas tarp BDD ir TDD yra dėmesys ir formuluotė. Ir žodžiai yra svarbūs perteikiant jūsų ketinimus.

TDD dėmesys skiriamas bandymams. Ir kadangi „senajame krioklio pasaulyje“ testai atliekami po įgyvendinimo, šis mąstymas sukelia nesusipratimus ir elgesį.

BDD dėmesys sutelkiamas į elgesį ir specifikaciją, todėl krioklio sužvejotas kiekis yra sutrikus. Taigi BDD yra lengviau suprantamas kaip projektavimo praktika, o ne kaip bandymų praktika.

17
08 сент. Atsakymą pateikė Juha Pohjalainen. 2008-09-08 21:36 '08 at 9:36 pm 2008-09-08 21:36

Atrodo, yra dviejų tipų BDD.

Pirmasis yra originalus stilius, apie kurį kalbėjo Danas ir dėl kurio atsirado xBehave stiliaus rėmai. Man šis stilius visų pirma yra taikomas domenų objektų priėmimo testams arba specifikacijoms.

Antrasis stilius yra tai, ką Dave Astels populiarino, ir man tai nauja TDD forma, kuri turi tam tikrų svarbių privalumų. Jame pagrindinis dėmesys skiriamas elgesiui, o ne bandymams, taip pat mažoms bandymų klasėms, bandant patekti į tašką, kuriame iš esmės yra viena eilutė kiekvienam specifikacijos metodui (testas). Šis stilius tinka visiems testavimo lygiams ir gali būti atliekamas naudojant bet kurią esamą modulinę testavimo sistemą, nors naujesnės struktūros (xSpec stilius) padeda sutelkti dėmesį į elgesį, o ne į bandymus.

Taip pat yra BDD grupė, kuri jums gali būti naudinga:

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

13
10 сент. Atsakymas suteikiamas Colin Jack 10 Sep. 2008-09-10 19:00 '08, 7 val. 2008-09-10 19:00

Aš šiek tiek eksperimentavau su BDD metodu, ir mano ankstyva išvada yra ta, kad BDD puikiai tinka atvejų įgyvendinimui, bet ne pagrindinėms detalėms. Šiame lygmenyje TDD vis dar sukasi.

BDD taip pat naudojamas kaip ryšio priemonė. Tikslas yra parašyti vykdomąsias specifikacijas, kurias gali suprasti domeno ekspertai.

6
27 авг. atsakymas Thomas Eyde 27 rug. 2008-08-27 23:59 '08 at 23:59 pm 2008-08-27 23:59

„Test-Driven Development“ yra programinės įrangos kūrimo testavimo metodika, o tai reiškia, kad norint parašyti tikrinamą kodą, kurį reikia išbandyti, turite parašyti testo kodą. Kento Bexo žodžiais:

Stilius yra parašyti keletą kodų eilučių, o tada bandymas, kuris turėtų veikti arba dar geriau parašyti testą, kuris neveiks, ir tada parašykite kodą, kuris leis jam dirbti.

Po to, kai išsiaiškinome, kaip parašyti vieną nedidelį kodą, vietoj tiesiog kodavimo, norime gauti tiesioginę grįžtamąjį ryšį ir šiek tiek „darbo“, šiek tiek testavimo, šiek tiek bandymų. Todėl mes iš karto parašysime testą.

Taigi TDD yra žemo lygio techninė metodika, kurią programuotojai naudoja norėdami sukurti švarų kodą, kuris veikia.

Elgsenos plėtra yra metodika, sukurta remiantis TDD, bet plėtojama ne tik programuotojams ir testuotojams, bet ir visai komandai bei visiems svarbiems techniniams ir netechniniams suinteresuotiesiems subjektams. BDD prasidėjo keliais paprastais klausimais, kuriuos TDD neatsako: kiek bandymų turėčiau rašyti? Ką turėčiau patikrinti ir ką turėčiau daryti? Kuris iš mano parašytų testų iš tikrųjų bus svarbus verslui ar visuotinei produkto kokybei, ir tai tik mano pernelyg didelė inžinerija?

Kaip matote, tokie klausimai reikalauja bendradarbiavimo tarp technologijų ir verslo. Verslo suinteresuotieji subjektai ir srities ekspertai dažnai gali inžinieriams pasakyti, kokie bandymai atrodo naudingi, bet tik jei bandymai yra aukšto lygio testai, skirti spręsti svarbius verslo aspektus. BDD tokius verslo testus vadina „pavyzdžiais“, kaip „pasakykite man, kaip ši funkcija turėtų tinkamai elgtis“, ir pasilieka žodį „testas“ žemo lygio techniniams patikrinimams, pvz., Duomenų tikrinimui ar API integracijos bandymui. Svarbiausia yra tai, kad, nors bandymus gali sukurti tik programuotojai ir testuotojai, pavyzdžius gali rinkti ir analizuoti visa pristatymo komanda - dizaineriai, analitikai ir kt.

Pasiūlymas pasižymi vienu iš geriausių BDD apibrėžimų, kuriuos iki šiol nustatiau, kad BDD „bendrauja su domeno ekspertais ir naudojasi pavyzdžiais, kad gautų bendrą supratimą apie norimą elgesį ir nustatytų nežinomus“. Dalis atradimo yra labai svarbi. Kadangi pristatymo komanda renka daugiau pavyzdžių, jie vis labiau pradeda suprasti verslo sritį ir taip mažina jų netikrumą dėl tam tikrų produkto aspektų, su kuriais jie turi susidurti. Mažėjant neapibrėžtumui, didėja pristatymo komandos kūrybiškumas ir autonomija. Pavyzdžiui, dabar jie gali pasiūlyti savo pavyzdžius, kad verslo vartotojai nemanė, kad jie galimi dėl techninių žinių trūkumo.

Dabar pokalbiai su verslo ir domenų ekspertais puikiai skamba, bet mes visi žinome, kaip dažnai jis baigiasi. Aš pradėjau savo kelionę su technologija kaip programuotojas. Kaip programuotojai mokome rašyti kodų algoritmus, dizaino modelius, abstrakcijas. Arba, jei esate dizaineris, esate mokomi kurti, tvarkyti informaciją ir sukurti gražias sąsajas. Bet kai gauname pradinio lygio darbo vietas, mūsų darbdaviai tikisi, kad „suteiksime vertę klientams“. Ir tarp šių klientų gali būti, pavyzdžiui, ... bankas. Bet beveik nieko nežinojau apie bankininkystę - be to, kaip efektyviai sumažinti savo sąskaitos likutį. Todėl turėčiau kažkaip išversti tai, ko tikimasi iš manęs į kodą ... Norėčiau suteikti tam tikrą vertę, kad turėčiau sukurti tiltą tarp bankininkystės paslaugų ir mano techninės kompetencijos. BDD padeda sukurti tokį tiltą stabiliu pagrindu informacijos mainams tarp pristatymo komandos ir šios srities ekspertų.

Skaityti daugiau

Jei norite daugiau sužinoti apie BDD, parašiau knygą šia tema. „Didelių specifikacijų rašymas“ nagrinėja reikalavimų analizės meną ir padeda jums sužinoti, kaip sukurti didelį BDD procesą ir naudoti pavyzdžius kaip pagrindinę šio proceso dalį. Knygoje kalbama apie visur egzistuojančią kalbą, pavyzdžių rinkimą ir vadinamųjų vykdomųjų specifikacijų (automatinių testų) sukūrimą iš pavyzdinių metodų, kurie padeda BDD komandoms laiku ir į biudžetą pristatyti puikią programinę įrangą.

Jei Jus domina pirkti „Puikių specifikacijų rašymas“, galite sutaupyti 39% reklamos kodo 39nicieja2 :)

5
12 февр. Atsakymas pateikiamas 12 vasario mėn. 2017-02-12 19:43 '17, 19:43 pm 2017-02-12 19:43

Man atrodo, kad BDD yra platesnis. Tai beveik reiškia, kad TDD yra naudojama, kad BDD yra išsami metodika, kuri renka informaciją ir reikalavimus, be kita ko, naudodama TDD metodus, kad būtų galima greitai pateikti atsiliepimus.

2
05 авг. atsakymas pateikiamas palehorse 05 rug . 2008-08-05 19:11 '08 at 7:11 pm 2008-08-05 19:11

Atrodo, kad elgsenos skatinamasis vystymasis labiau orientuojasi į kūrėjų ir kūrėjų bei testuotojų sąveiką ir bendravimą.

Vikipedijos straipsnyje yra paaiškinimas:

Elgesio raida

Negalima praktikuoti BDD.

2
05 авг. Atsakymą pateikė Michael Stum 05 rug . 2008-08-05 19:06 '08, 19:06 pm 2008-08-05 19:06

BDD yra gana daug TDD padaryta teisingai. Tačiau BDD siūlo pridėtinę vertę. Čia yra nuoroda į šį:

BDD yra didesnis nei „TDD padaryta teisė“

2
29 июля '10 в 13:25 2010-07-29 13:25 Atsakymą davė Neelis liepos 29 d. 10 val. 13:25 2010-07-29 13:25

Dėl savo naujausių žinių apie BDD, palyginti su TDD, BDD daugiausia dėmesio skiria nustatymui, kas ateina, o TDD daugiausia dėmesio skiria sąlygų rinkiniui ir tada - išėjimui.

2
25 мая '09 в 7:09 2009-05-25 07:09 atsakymą pateikė Uma Mahesh Varma gegužės 09 d., 07:09 2009-05-25 07:09

Apsvarstykite pagrindinį TDD privalumą kaip dizainą. Jis turėtų būti vadinamas „Test Driven Design“. BDD - tai TDD, vadinamo elgesiu pagrįstas dizainas, pogrupis.

Dabar apsvarstykite populiarų TDD įrenginio testavimo įgyvendinimą. Vienetų testavimo vienetai paprastai yra viena logika, kuri yra mažiausias darbo vienetas, kurį galite atlikti.

Įdėję šiuos įrenginius funkciniu būdu, norėdami apibūdinti norimą mašinos veikimą, turite suprasti elgesį, kurį aprašėte mašinoje. Į elgesį orientuotas dizainas orientuojasi į kūrėjų supratimo apie naudojimo atvejus / reikalavimus / nepriklausomai nuo to, ar ir kaip kiekviena funkcija atliekama. BDD ir TDD paprastai yra svarbūs tikslai informuoti projektą ir antrąjį tikslą patvirtinti įgyvendinimą, ypač kai jis keičiasi. Teisingai atliekami BDD yra „biz“ ir „dev“ (ir qa) funkcijos, o vieneto testavimas (galbūt neteisingai laikomas TDD, o ne vieno tipo TDD) paprastai atliekamas „dev silo“.

Norėčiau pridurti, kad BDD testai yra gyvybiškai svarbūs.

2
29 мая '15 в 1:36 2015-05-29 01:36 Atsakymą pateikė filmas v. Gegužės 29 d., „15, 1:36 2015-05-29 01:36

Skirtumas tarp bandymų kūrimo (TDD) ir elgesio valdymo (BDD)

  • BDD orientuojasi į sistemos elgesio aspektą, o ne į sistemos diegimo aspektą, kurį TDD skiria.

  • BDD pateikia aiškesnį supratimą apie tai, ką sistema turėtų daryti kūrėjo ir kliento požiūriu. Tik Tdd
    suteikia kūrėjui supratimą apie tai, ką sistema turėtų daryti.

  • BDD leidžia tiek kūrėjui, tiek klientui dirbti kartu su reikalavimų analize, kuri yra sistemos pradiniame kode.

1
10 июня '17 в 2:49 2017-06-10 02:49 Atsakymas, kurį pateikė rahul patil Birželio 10 d. 17, 2:49 2017-06-10 02:49

Čia yra greitas momentinis vaizdas:

  • TDD yra tik kodo patikrinimo procesas prieš jį rašant!

  • DDD yra informavimo apie domeną procesas prieš kiekvieną kodo palietimo ciklą!

  • BDD yra TDD įgyvendinimas, kuriame pristatomi kai kurie DDD aspektai!

Tikiuosi, kad tai padės!

1
18 янв. atsakymą pateikė Snehal Masne 18 sausio. 2016-01-18 06:01 '16 at 6:01 am 2016-01-18 06:01

Pasirinkimas tarp TDD ir BDD yra sudėtingas. Tai priklauso nuo to, ar jūsų tikslinei kalbai yra tinkama testavimo struktūra, su kuria jūsų darbuotojai yra patogūs, o kartais ir su kitais veiksniais.

Kai kurie teigia, kad BDD visada yra geresnis už TDD, nes jis gali pašalinti problemas, kurios gali kilti naudojant TDD.

Raktas į BDD yra tai, kad jis gali užkirsti kelią problemoms; Jis nėra garantuotas. Problemos, pavyzdžiui, blogo kodo organizavimas, blogos dizaino praktikos ir kt. Jums bus mažiau tikėtina, kad parašysite blogus testus, todėl turėsite patikimesnes funkcijas.

0
18 сент. Atsakymą pateikė Bhushan rugsėjo 18 d 2016-09-18 12:59 '16 at 12:59 pm 2016-09-18 12:59

Tarp TDD ir BDD nėra skirtumo. išskyrus tai, kad galite geriau perskaityti savo testus ir galite juos naudoti kaip reikalavimus. Jei rašote savo reikalavimus tais pačiais žodžiais, kaip rašant BDD testus, galite ateiti iš savo kliento, kad kai kurie jūsų testai būtų paruošti kodui rašyti.

0
07 окт. Atsakymas, kurį pateikė Mihai 07 spalis 2014-10-07 11:52 '14 at 11:52 am 2014-10-07 11:52

Šis dienoraštis pateikia įdomų požiūrį į skirtumus tarp TDD, BDD ir ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

-1
20 мая '14 в 21:32 2014-05-20 21:32 atsakymą pateikė vartotojo3632158 gegužės 20 '14, 21:32 2014-05-20 21:32

Kiti klausimai apie žymes arba Užduoti klausimą