Hva er de viktigste forskjellene mellom TDD og BDD?

stemmer
120

Test Driven Development har vært raseri i .NET samfunnet for de siste årene. Nylig har jeg hørt grumblings i ALT.NET samfunnet om BDD. Hva er det? Hva gjør den forskjellig fra TDD?

Publisert på 05/08/2008 klokken 15:58
kilden bruker
På andre språk...                            


15 svar

stemmer
96

Jeg forstår BDD å være mer om spesifikasjoner enn testing . Den er knyttet til Domain Driven Design (ikke du elsker disse * DD akronymer?).

Det er knyttet til en bestemt måte å skrive brukerhistorier, inkludert høyt nivå tester. Et eksempel av Tom ti 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

(I sin artikkel, går Tom på å utføre denne testen spesifikasjon i Ruby direkte.)

Paven av BDD er Dan Nord . Du finner en flott introduksjon i hans presenterer BDD artikkelen.

Du vil finne en sammenligning av BDD og TDD i denne videoen . Også en mening om BDD som "TDD gjort riktig" av Jeremy D. Miller

25 mars 2013 oppdatering

Videoen ovenfor har vært savnet en stund. Her er en fersk en av Llewellyn Falco, BDD vs TDD (forklart) . Jeg finner hans forklaring tydelig og rett på sak.

Svarte 05/08/2008 kl. 16:36
kilden bruker

stemmer
17

For meg primære forskjellen mellom BDD og TDD er fokus og ordlyden. Og ordene er viktig for å kommunisere dine ønsker.

TDD dirigerer fokus på testing. Og siden i "gamle foss verden" testene kommer etter implementering, så denne tankegangen fører til feil forståelse og atferd.

BDD dirigerer fokus på atferd og spesifikasjon, og så fossen sinn er distrahert. Så BDD er lettere forstås som designpraksis og ikke som testing praksis.

Svarte 08/09/2008 kl. 18:36
kilden bruker

stemmer
13

Det synes å være to typer BDD.

Den første er den opprinnelige stilen som Dan Nord diskuterer og som forårsaket etableringen av xBehave stil rammer. For meg denne stilen er først og fremst aktuelt for aksept testing eller spesifikasjoner mot domene stedene.

Den andre stilen er hva Dave Astels popularisert og som, for meg, er en ny form for TDD som har noen alvorlige fordeler. Det fokuserer på atferd snarere enn testing og også små test klasser, prøver å få til et punkt der du i utgangspunktet har en linje per spesifikasjon (test) metoden. Denne stilen passer alle nivåer av testing og kan gjøres ved hjelp av en eksisterende enhet testing rammeverk om nyere rammer (xSpec stil) bidra til å fokusere en atferd snarere enn testing.

Det er også en BDD gruppe som du kan finne nyttig:

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

Svarte 10/09/2008 kl. 16:00
kilden bruker

stemmer
7

Test-Driven Development er en test-første programvareutviklingsmetodikk, noe som betyr at det krever skriftlig test kode før du skriver selve koden som skal testes. I Kent Beck ord:

Stilen her er å skrive noen få linjer med kode, og deretter en test som skal kjøre, eller enda bedre, for å skrive en test som ikke vil kjøre, deretter skrive kode som vil gjøre det kjøres.

Etter å finne ut hvordan du skal skrive en liten kode, nå, i stedet for bare koding på, ønsker vi å få umiddelbar tilbakemelding og praksis "code litt, teste litt, kode litt, teste litt." Så vi umiddelbart skrive en test for det.

Så TDD er et lavt nivå, teknisk metode som programmerere bruker til å produsere ren kode som fungerer.

Oppførelsdrevet utvikling er en metode som ble laget basert på TDD, men utviklet seg til en prosess som ikke angår bare programmerere og testere, men i stedet for seg hele teamet og alle viktige interessenter, tekniske og ikke-tekniske. BDD startet av et par enkle spørsmål som TDD ikke svarer godt: hvor mye tester skal jeg skrive? Hva skal jeg faktisk teste og hva bør jeg ikke? Hvilken av de testene jeg skriver blir faktisk viktig for virksomheten eller til den generelle kvaliteten på produktet, og som er bare min over-ingeniør?

Som du kan se, slike spørsmål krever samarbeid mellom teknologi og forretning. Interessenter og domene eksperter ofte kan fortelle ingeniører hva slags tester høres ut som de ville være nyttig, men bare hvis testene er høyt nivå tester som omhandler viktige forretningsmessige aspekter. BDD kaller slike forretningslignende tester “eksempler”, som i “fortelle meg et eksempel på hvordan denne funksjonen skal opptre korrekt”, og forbeholder ordet “test” for lavt nivå, teknisk kontroll for eksempel datavalidering eller testing API integrasjoner. Det viktige er at mens testene kan bare skapes av programmerere og testere, eksempler kan samles inn og analyseres av hele leveransen team-av designere, analytikere, og så videre.

I en setning, en av de beste definisjonene av BDD jeg har funnet så langt er at BDD handler om “å ha samtaler med domene eksperter og bruker eksempler for å få en felles forståelse for ønsket atferd og oppdage ukjente.” Oppdagelsen delen er svært viktig . Som levering team samler flere eksempler, de begynner å forstå virksomheten domene mer og mer, og dermed de redusere usikkerhet om noen aspekter av produktet de har å forholde seg til. Som usikkerhet minsker, kreativitet og selvstendighet for levering team økningen. For eksempel kan de nå begynne å foreslå egne eksempler på at forretningsbrukere trodde ikke var mulig på grunn av deres mangel på teknisk kompetanse.

Nå, etter å ha samtaler med næringslivet og domene eksperter høres flott ut, men vi vet alle hvordan det ofte ender opp i praksis. Jeg begynte min reise med tech som programmerer. Som programmerere, er vi lært å skrive kode -algorithms, design mønstre, abstraksjoner. Eller, hvis du er en designer, er du lærer å designe organiser informasjon og skape vakre grensesnitt. Men når vi får våre entry-level jobber, våre arbeidsgivere forventer oss å "levere verdi til kundene." Og blant disse klientene kan være, for eksempel ... en bank. Men jeg kunne vet nesten ingenting om bank-bortsett fra hvordan du effektivt redusere min konto. Så jeg måtte liksom oversette hva som forventes av meg inn kode ... Jeg ville ha å bygge en bro mellom bank og min tekniske kompetanse om jeg ønsker å levere noen verdi. BDD hjelper meg å bygge en slik bro på et stabilt fundament av fluidforbindelse mellom levering team og domene eksperter.

Lære mer

Hvis du ønsker å lese mer om BDD, jeg skrev en bok om emnet. “Skrive Stor Spesifikasjoner” utforsker kunsten å analysere krav og vil hjelpe deg å lære å bygge en stor BDD prosess og bruker eksempler som en sentral del av denne prosessen. Boken forteller om den allestedsnærværende språk, samle eksempler, og skaper såkalte kjør spesifikasjoner (automatiserte tester) ut av eksemplene-teknikker som hjelper BDD lag levere god softeware i tide og på budsjett.

Hvis du er interessert i å kjøpe “Skrive Gode spesifikasjoner,” du kan spare 39% med en kampanjekode 39nicieja2 :)

Svarte 12/02/2017 kl. 16:43
kilden bruker

stemmer
6

Jeg har eksperimentert litt med BDD tilnærming og min tidlig konklusjon er at BDD er godt egnet til å bruke saken gjennomføring, men ikke på de underliggende detaljene. TDD fortsatt rock på det nivået.

BDD blir også brukt som et verktøy. Målet er å skrive kjørbare spesifikasjoner som kan forstås av domene eksperter.

Svarte 27/08/2008 kl. 20:59
kilden bruker

stemmer
2

Vurdere primære fordelen med TDD å være design. Det bør bli kalt Test Driven Design. BDD er en undergruppe av TDD, kaller det Behavior Driven Design.

Nå vurdere en populær implementering av TDD - Unit Testing. Enhetene i Unit Testing er vanligvis en bit av logikk som er den minste enheten av arbeid du kan gjøre.

Når du setter disse enhetene sammen på en funksjonell måte å beskrive ønsket atferd til maskinene, må du forstå atferd du beskriver til maskinen. Behavior Driven Design fokuserer på å verifisere implementers forståelse av bruksmåter / Krav / Uansett og verifiserer gjennomføringen av hver funksjon. BDD og TDD generelt tjener den viktige formål å informere utforming og det andre formål å bekrefte riktigheten av å gjennomføre, spesielt når den endres. BDD gjort riktig innebærer biz og dev (og QA), mens Unit Testing (muligens feilaktig oppfattes som TDD snarere enn en type TDD) blir vanligvis gjort i den dev siloen.

Jeg vil legge til at BDD tester tjene som levende krav.

Svarte 28/05/2015 kl. 22:36
kilden bruker

stemmer
2

BDD er i stor grad TDD gjort riktig. Men det er ekstra verdi som BDD tilbyr. Her er en link på at:

BDD er mer enn “TDD gjort riktig”

Svarte 29/07/2010 kl. 10:25
kilden bruker

stemmer
2

Med min nyeste kunnskapen i BDD sammenlignet med TDD, fokuserer BDD om angivelse av hva som vil skje videre, mens TDD fokuserer på å sette opp et sett av betingelser og deretter se på utgangen.

Svarte 25/05/2009 kl. 04:09
kilden bruker

stemmer
2

Det virker for meg at BDD er et bredere omfang. Det innebærer nesten TDD er brukt, at BDD er encompasing metodikk som samler informasjon og krav for bruk, amongh annet å TDD praksis sikre rask tilbakemelding.

Svarte 05/08/2008 kl. 16:11
kilden bruker

stemmer
2

Oppførelsdrevet utvikling ser ut til å fokusere mer på samhandling og kommunikasjon mellom utviklere og også mellom utviklere og testere.

Wikipedia-artikkelen har en forklaring:

Oppførelsdrevet utvikling

Ikke praktiserer BDD meg selv om.

Svarte 05/08/2008 kl. 16:06
kilden bruker

stemmer
1

Forskjellen mellom testdrevet utvikling (TDD) og oppførelsdrevet utvikling (BDD)

  • BDD fokuserer på atferds aspekt ved systemet i stedet for
    implementering aspekt ved systemet som TDD fokuserer på.

  • BDD gir en klarere forståelse om hva systemet skal gjøre
    fra perspektivet av utbygger og kunden. TDD bare
    gir utvikleren en forståelse av hva systemet skal gjøre.

  • BDD gjør at både utbygger og kunden til å arbeide sammen for å på behovsanalyse som finnes i kildekoden til systemet.

Svarte 09/06/2017 kl. 23:49
kilden bruker

stemmer
1

Her er øyeblikksbilde:

  • TDD er bare prosessen med testing kode før du skriver det!

  • DDD er ferd med å bli informert om Domain før hver syklus av å berøre koden!

  • BDD er en implementering av TDD som bringer i noen aspekter av DDD!

Håper det hjelper!

Svarte 18/01/2016 kl. 03:01
kilden bruker

stemmer
0

Valget mellom TDD og BDD er komplisert. Det avhenger av om det er en passende testing rammeverk for gitt målspråket, hva dine kolleger er komfortabel med, og noen ganger andre faktorer.

Noen hevder at BDD er alltid bedre enn TDD fordi den har mulighet til å utelukke problemer som kan oppstå ved bruk av TDD.

Nøkkelen til BDD er at det kan forebygge problemer; det er ikke garantert å. Problemer som dårlig koden organisering, dårlig design praksis, etc. vil fortsatt vedvarer. Du vil bare ha en lavere sannsynlig hette av å skrive dårlige tester og dermed har mer robuste funksjoner.

Svarte 18/09/2016 kl. 09:59
kilden bruker

stemmer
0

Det er ingen forskjell betwen TDD og BDD. bortsett fra at du kan lese tester bedre, og du kan bruke dem som krav. Hvis du skriver dine krav med de samme ordene som du skriver BDD tester så kan du komme Frome din klient med noen av testene definert klar til å skrive kode.

Svarte 07/10/2014 kl. 08:52
kilden bruker

stemmer
-1

Denne bloggen gir et interessant synspunkt på forskjellene mellom TDD, BDD, og ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd-bdd-atdd/

Svarte 20/05/2014 kl. 18:32
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more