Hvornår skriver du den "rigtige" kode i TDD?

johnny 09/15/2017. 11 answers, 20.464 views
tdd

Alle de eksempler, jeg har læst og set på træningsvideoer, har forenklede eksempler. Men hvad jeg ikke kan se om, hvordan jeg gør den "rigtige" kode efter jeg bliver grøn. Er dette "Refactor" -delen?

Hvis jeg har et ret komplekst objekt med en kompleks metode, og jeg skriver min test og det absolutte minimum for at få det til at passere (efter det først fejler Rød). Hvornår går jeg tilbage og skriver den rigtige kode? Og hvor meget rigtig kode skriver jeg, inden jeg genfremsætter? Jeg gætter på, at den sidste er mere intuition.

Edit: Tak til alle, der svarede. Alle dine svar hjalp mig uhyre. Der synes at være forskellige ideer om, hvad jeg spurgte eller forvirrede om, og måske er der, men det, jeg spurgte var, siger jeg har en ansøgning om at opbygge en skole.

I mit design har jeg en arkitektur, jeg vil starte med, User Stories osv. Osv. Herfra tager jeg disse User Stories, og jeg opretter en test for at teste User Story. Brugeren siger: Vi har folk tilmeldt skolen og betaler registreringsgebyrer. Så jeg tænker på en måde at gøre det mislykkes. Dermed designer jeg en testklasse til klasse X (måske studerende), som vil mislykkes. Jeg opretter derefter klassen "Student". Måske "Skole" ved jeg ikke.

Men i hvert fald tvinger TD Design mig til at tænke igennem historien. Hvis jeg kan lave en testfejl, ved jeg hvorfor det fejler, men det forudsætter, at jeg kan få det til at passere. Det handler om design.

Jeg ligner dette at tænke på Rekursion. Rekursion er ikke et hårdt koncept. Det kan være sværere at faktisk holde øje med det i dit hoved, men i virkeligheden ved den sværeste del at vide, hvornår rekursionen "bryder", hvornår skal man stoppe (min mening selvfølgelig.) Så jeg skal tænke over, hvad der stopper Rekursionen først. Det er kun en ufuldkommen analogi, og det forudsætter, at hver rekursiv iteration er et "pass". Igen, bare en mening.

I implementeringen er skolen sværere at se. Numeriske og bankbøger er "nemme" i den forstand, at du kan bruge simpel aritmetik. Jeg kan se en + b og returnere 0 osv. I tilfælde af et system af mennesker, skal jeg tænke hårdere på, hvordan man implement det. Jeg har begrebet fejl, pass, refactor (hovedsagelig på grund af undersøgelse og dette spørgsmål.)

Hvad jeg ikke ved, er baseret på manglende erfaring, efter min mening. Jeg ved ikke, hvordan man skal undlade at tilmelde sig en ny elev. Jeg ved ikke, hvordan man kan svigte nogen, der skriver i et efternavn, og det bliver gemt i en database. Jeg ved, hvordan man laver en + 1 for simpel matematik, men med enheder som en person ved jeg ikke, om jeg kun tester for at se, om jeg får et unikt id eller noget andet, når nogen går ind i et navn i en database eller begge dele eller hverken.

Eller måske viser det mig, at jeg stadig er forvirret.

5 Comments
187 hobbs 07/25/2017
Efter TDD-folkene går hjem til natten.
14 Goyo 07/25/2017
Hvorfor tror du, at koden du skrev, ikke er ægte?
2 johnny 07/26/2017
@RubberDuck Mere end de andre svar gjorde. Jeg er sikker på, at jeg snart vil henvise til det. Det er stadig lidt udenlandsk, men jeg vil ikke give op på det. Hvad du sagde var fornuftigt. Jeg forsøger bare at gøre det fornuftigt i min sammenhæng eller en almindelig forretningsapplikation. Måske et lager system eller lignende. Jeg skal overveje det. Jeg er taknemmelig for din tid selv. Tak.
1 Edmund Reed 07/26/2017
Svarene har allerede ramt neglen på hovedet, men så længe alle dine tests er ved at passere, og du ikke har brug for nye test / funktionalitet, kan det antages, at koden du har er færdig, bar linting.
3 Borjab 07/26/2017
Der er en asumption i spørgsmålet, der kan være problematisk i "Jeg har et ret komplekst objekt med en kompleks metode". I TDD skriver du dine test først, så du starter med en ret simpel kode. Dette vil tvinge dig til at kode en testvenlig struktur, der skal moduleres. Så kompleks adfærd vil blive skabt ved at kombinere enklere objekter. Hvis du slutter med et ret komplekst objekt eller metode, så er det når du refactor

11 Answers


RubberDuck 07/27/2017.

Hvis jeg har et ret komplekst objekt med en kompleks metode, og jeg skriver min test og det absolutte minimum for at få det til at passere (efter det først fejler Rød). Hvornår går jeg tilbage og skriver den rigtige kode? Og hvor meget rigtig kode skriver jeg, inden jeg genfremsætter? Jeg gætter på, at den sidste er mere intuition.

Du "går ikke tilbage" og skriver "rigtig kode". Det er al rigtig kode. Hvad du gør, er at gå tilbage og tilføj en anden test, der forces dig til at change din kode for at få den nye testpas.

Hvad angår hvor meget kode skriver du før du genoptræder? Ingen. Du skriver zero kode uden en fejlagtig test, der forces dig til at skrive mere kode.

Bemærk mønsteret?

Lad os gå igennem (et andet) simpelt eksempel i håb om at det hjælper.

 Assert.Equal("1", FizzBuzz(1)); 

Nem peazy.

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

Ikke hvad du ville kalde rigtig kode, ikke? Lad os tilføje en test, der tvinger en ændring.

 Assert.Equal("2", FizzBuzz(2)); 

Vi kunne gøre noget dumt, if n == 1 , men vi hopper over til den kloge løsning.

 public String FizzBuzz(int n) {
    return n.ToString();
} 

Fedt nok. Dette vil fungere for alle ikke-FizzBuzz numre. Hvad er det næste input, der vil tvinge produktionskoden til at ændre?

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

Og igen. Skriv en test, der ikke vil bestå endnu.

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

Og vi har nu dækket alle multipler af tre (det er ikke også multipler af fem, vi noterer det og kommer tilbage).

Vi har ikke skrevet en test for "Buzz" endnu, så lad os skrive det.

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

Og igen ved vi, at der er en anden sag, vi skal håndtere.

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

Og nu kan vi klare alle multipler af 5, der ikke også er multipler af 3.

Indtil dette punkt har vi ignoreret refactoringstrinnet, men jeg ser en vis dobbeltarbejde. Lad os rydde op nu.

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Fedt nok. Nu har vi fjernet duplikationen og oprettet en godt navngivet funktion. Hvad er den næste test, vi kan skrive, der vil tvinge os til at ændre koden? Nå har vi undgået sagen, hvor tallet er deleligt med både 3 og 5. Lad os skrive det nu.

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Testene bestå, men vi har mere dobbeltarbejde. Vi har muligheder, men jeg vil anvende "Uddrag lokal variabel" et par gange, så vi refactoring i stedet for at omskrive.

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

Og vi har dækket alle rimelige input, men hvad med unreasonable input? Hvad sker der, hvis vi passerer 0 eller en negativ? Skriv disse test sager.

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

Er dette begyndt at ligne "rigtig kode" endnu? Endnu vigtigere, på hvilket tidspunkt ophørte det med at være "uvirkelig kode" og overgang til at være "rigtig"? Det er noget at overveje på ...

Så jeg kunne bare gøre det ved at kigge efter en test, som jeg vidste ikke ville passere ved hvert trin, men jeg har haft en masse øvelse. Når jeg er på arbejde, er tingene ikke altid så enkle, og jeg kan ikke altid vide, hvad testen vil tvinge en forandring. Nogle gange vil jeg skrive en test og være overrasket over at se det allerede passerer! Jeg anbefaler stærkt, at du bliver vant til at oprette en "testliste", før du kommer i gang. Denne testliste skal indeholde alle de "interessante" input du kan tænke på. Du kan muligvis ikke bruge dem alle, og du vil sandsynligvis tilføje tilfælde, mens du går, men denne liste tjener som køreplan. Min testliste for FizzBuzz ville se sådan ud.

  • Negativ
  • Nul
  • En
  • To
  • Tre
  • fire
  • Fem
  • Seks (ikke trivielt multiplum af 3)
  • Ni (3 kvadreret)
  • Ti (ikke trivielt multiplum af 5)
  • 15 (flere af 3 og 5)
  • 30 (ikke trivielt multiplum af 3 & 5)
5 comments
3 maple_shaft♦ 07/27/2017
Kommentarer er ikke til udvidet diskussion; denne samtale er blevet flyttet til chat .
40 GManNickG 07/27/2017
Medmindre jeg helt misforstår dette svar: "Vi kunne gøre noget dumt, hvis n == 1, men vi hopper over til den kloge løsning." - Det hele var dumt. Hvis du kender op foran, har du brug for en funktion, der gør <spec>, skriv test for <spec> og spring over den del, hvor du skriver versioner, der naturligvis fejler <spec>. Hvis du finder en fejl i <spec> så sørg for: Skriv en test først for at bekræfte, at du kan udøve den før reparationen og observere testpasningerne efter reparationen. Men der er ingen grund til at falske alle disse mellemliggende trin.
15 user3791372 07/28/2017
De kommentarer, der påpeger de store fejl i dette svar og TDD generelt er blevet flyttet til chat. Hvis du overvejer at bruge TDD, skal du læse "chat". Desværre er "kvalitet" kommentarer nu gemt blandt en masse chat for fremtidige elever at læse.
nbro 07/28/2017
Jeg ville være mere præcis med hensyn til indholdet af denne "testliste", hvis du ønskede at forbedre dette svar. Jeg vil udtrykkeligt tale om "grænseværdier" og "klassepartitionering".
2 hvd 07/30/2017
@GManNickG Jeg tror, ​​at pointen er at få den rigtige mængde tests. Ved at skrive testene på forhånd gør det nemt at gå glip af, hvilke specielle tilfælde der skal testes, hvilket fører til, at situationer ikke dækkes tilstrækkeligt i testene, eller at i det væsentlige den samme situation er uden betydning dækket mange gange i testene. Hvis du kan gøre det uden disse mellemliggende trin, fantastisk! Ikke alle kan gøre det alligevel, det er noget, der kræver øvelse.

GenericJon 07/24/2017.

Den "rigtige" kode er koden du skriver for at gøre dit testpas. Really . Det er så simpelt.

Når folk taler om at skrive det rene minimum for at gøre testen grøn, betyder det bare, at din rigtige kode skal følge YAGNI-princippet .

Ideen om refaktortrin er bare at rydde op, hvad du har skrevet, når du er glad for at den opfylder kravene.

Så længe de tests, du skriver, faktisk dækker dine produktkrav, så snart koden er færdig, er koden færdig. Tænk på det, hvis alle dine forretningsbehov har en test, og alle disse test er grønne, hvad mere er der til at skrive? (Okay, i det virkelige liv har vi ikke en tendens til at have fuldstændig testdækning, men teorien er lyd.)

5 comments
44 Derek Elkins 07/24/2017
Enhedstest kan faktisk ikke dække dine produktkrav til selv relativt trivielle krav. I bedste fald prøver de input-output-rummet, og ideen er, at du (korrekt) generaliserer til det fulde input-output-rum. Selvfølgelig kan din kode bare være en stor switch med et tilfælde for hver enhedsprøve, som ville passere alle test og mislykkes for andre indgange.
8 Taemyr 07/25/2017
@DerekElkins TDD bemyndiger manglende tests. Manglende enhedstest.
6 jonrsharpe 07/25/2017
@DerekElkins derfor skriver du ikke enhedstests, og også hvorfor er der en generel antagelse om, at du forsøger at lave noget, ikke bare falske det!
35 Derek Elkins 07/25/2017
@jonrsharpe Ved den logik ville jeg aldrig skrive trivielle implementeringer. F.eks. I FizzBuzz-eksemplet i RubberDucks svar (som kun bruger enhedsprøver), forklarer den første implementering "bare bare det". Min forståelse af spørgsmålet er netop denne dikotomi mellem skrive kode, som du ved er ufuldstændig og kode, som du virkelig tror vil gennemføre kravet, den "rigtige kode". Min "store switch " var beregnet som en logisk ekstreme af "at skrive det minimale minimum for at gøre testene grønne". Jeg ser OP's spørgsmål som: hvor i TDD er princippet om at undgå denne store switch ?
2 Luaan 07/25/2017
@GenericJon Det er lidt for optimistisk i min oplevelse :) For en er der mennesker, der nyder tankeløst gentaget arbejde. De vil blive lykkeligere med en kæmpe switch-sætning end med en "kompliceret beslutningstagning". Og for at miste deres job, ville de enten have brug for nogen, der kalder dem ud på teknikken (og de har bedre gode beviser, at det faktisk taber virksomhedens muligheder / penge!), Eller gør usædvanligt dårligt. Efter at have overtaget vedligeholdelsen på mange sådanne projekter kan jeg fortælle, at det er nemt at holde meget naiv kode i årtier, så længe det gør kunden glad (og betaler).

Carl Raymond 07/24/2017.

Det korte svar er, at den "rigtige kode" er den kode, der får testen til at passere. Hvis du kan gøre din testpas med noget andet end ægte kode, tilføj flere tests!

Jeg er enig i, at mange tutorials om TDD er forenklede. Det virker imod dem. En for simpel test for en metode, der siger, beregner 3 + 8, har virkelig intet andet valg end at også beregne 3 + 8 og sammenligne resultatet. Det gør det til at se ud som om du bare skal duplikere kode hele tiden, og at testningen er meningsløs, fejlagtigt ekstra arbejde.

Når du er god til test, vil det informere om, hvordan du strukturerer din ansøgning, og hvordan du skriver din kode. Hvis du har problemer med at komme med fornuftige, hjælpsomme tests, skal du nok tænke på dit design lidt. Et veldesignet system er let at teste - hvilket betyder, at fornuftige tests er nemme at tænke på og at implementere.

Når du først skriver dine tests, så se dem mislykkes, og skriv derefter koden, der får dem til at passere. Det er en disciplin, der sikrer, at hele din kode har tilsvarende tests. Jeg følger ikke regelmæssigt denne regel, når jeg kodes ofte skriver jeg prøver efter fakta. Men at lave tests første hjælper med at holde dig ærlig. Med nogle erfaringer begynder du at lægge mærke til, når du selv kodes ind i et hjørne, selv når du ikke skriver prøver først.

4 comments
6 Steve Jessop 07/26/2017
Personligt vil den test, jeg skriver, være assertEqual(plus(3,8), 11) , ikke assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) . I mere komplekse tilfælde søger du altid et middel til at bevise resultatet korrekt, other than dynamisk beregning af det korrekte resultat i testen og kontrol af lighed.
Steve Jessop 07/26/2017
Så for en virkelig dum måde at gøre det til dette eksempel kan du bevise at plus(3,8) har returneret det korrekte resultat ved at trække 3 fra det, trække 8 fra det og kontrollere resultatet mod 0. Dette er så naturligt svarende til assertEqual(plus(3,8), 3+8) for at være lidt absurd, men hvis koden under test bygger noget mere kompliceret end blot et helt tal, så tager resultatet og kontrollerer hver del for korrekthed. den rigtige tilgang. Alternativt kan noget som for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
... da det undgår den store frygt, hvilket er, at når vi skriver testen, laver vi den samme fejl i emnet "hvordan man tilføjer 10", som vi lavede i live-koden. Så testen omhyggeligt undgår at skrive en kode, der tilføjer 10 til noget, i testen, at plus() kan tilføje 10 til ting. Vi er selvfølgelig stadig afhængige af programmerings-verificerede intensive loop værdier.
3 Warbo 07/28/2017
Ønsker bare at påpege, at selvom du skriver tests efter det, er det stadig en god ide at se dem fejle find en del af koden, som forekommer afgørende for det, du arbejder på, juster det lidt (fx erstatte en + med en eller hvad som helst), kør testene og se dem mislykkes, fortryd ændringen og se dem passere. Mange gange har jeg gjort det, testen fejler faktisk ikke, hvilket gør det værre end ubrugeligt: ​​det er ikke kun at teste noget, det giver mig falsk tillid til, at noget bliver testet!

Victor Cejudo 07/25/2017.

Nogle gange kan nogle eksempler på TDD være vildledende. Som andre mennesker har påpeget før, er koden du skriver for at lave prøver, den rigtige kode.

Men tror ikke, at den rigtige kode ser ud som magi - det er forkert. Du har brug for en bedre forståelse af, hvad du vil opnå, og så skal du vælge testen i overensstemmelse hermed, ud fra de letteste tilfælde og hjørnesager.

Hvis du f.eks. Skal skrive en lexer, starter du med en tom streng, så med en masse hvide rum, så et nummer, derefter med et tal omgivet af hvide rum, så et forkert nummer osv. Disse små transformationer vil føre dig til den rigtige algoritme, men du hopper ikke fra det letteste tilfælde til en meget kompleks sag valgt dumbly for at få den rigtige kode færdig.

Bob Martin forklarer det perfekt her .


CandiedOrange 07/25/2017.

Refactor-delen er ryddet op, når du er træt og vil hjem.

Når du er ved at tilføje en funktion, er refactordelen det, du ændrer før næste test. Du refactor koden for at gøre plads til den nye funktion. Du gør dette, når du know hvad den nye funktion vil være. Ikke når du bare forestiller dig det.

Dette kan være så simpelt som at omdøbe GreetImpl til GreetWorld før du opretter en GreetMom klasse (efter at have tilføjet en test) for at tilføje en funktion, der udskriver "Hej mor".


graeme 07/27/2017.

Men den rigtige kode vil fremgå i refaktorfasen af ​​TDD-fasen. Dvs. koden som skal være en del af den endelige udgave.

Test skal køres hver gang du foretager en ændring.

Modet for TDD livscyklus ville være: RØD GRØN REFAKTOR

RED : Skriv testene

GREEN : Lav et ærligt forsøg på at få funktionskode, der passerer test så hurtigt som muligt: ​​duplikat kode, uklart navngivne variabler hacks af højeste ordre osv.

REFACTOR : Ryd op koden, navngiv variablerne korrekt. Tør koden op.

5 comments
5 mcottle 07/25/2017
Jeg ved hvad du siger om den "grønne" fase, men det indebærer, at hard-wired-returværdier for at få testene til at passere, kan være passende. I min erfaring skal "Green" være et ærligt forsøg på at gøre arbejdskode for at opfylde kravet, men det skal måske ikke være perfekt, men det skal være så komplet og "shippable" som udvikleren kan klare i et første pass. Refactoring er sandsynligvis bedst gjort noget tid senere, efter at du har gjort mere udvikling, og problemerne med første pas bliver mere tydelige, og mulighederne for at DRY opstår.
graeme 07/25/2017
@ mcottle Jeg anser disse alle for en del af samme opgave. få det gjort, og ryd det op. Yderligere refactorings bør ske som tiden går som en del af andre opgaver.
1 Bryan Boettcher 07/25/2017
@ mcottle: Du kan blive overrasket over, hvor mange implementeringer af et kun-kun-depot kan være hardcoded-værdier i codebase. :)
6 Kaz 07/25/2017
Hvorfor skulle jeg nogensinde skrive crap-kode og rydde den op, når jeg kan køre fint ud, produktionskvalitetskoden næsten lige så hurtigt som jeg kan skrive? :)
1 Kaz 07/27/2017
@TimothyTruckle Hvad skal det tage 50 minutter at finde den enkleste mulige ændring, men kun 5 for at finde den nemmeste mulige ændring? Går vi med det næstbedste eller fortsætter med at søge efter enkleste?

Timothy Truckle 07/27/2017.

Hvornår skriver du den "rigtige" kode i TDD?

Den red fase er hvor du write kode.

I refactoring det primære mål at delete kode.

I den red fase gør du noget for at gøre testen as quick as possible og at any cost . Du ignorerer helt hvad du nogensinde har hørt om god kodning praksis eller design mønster ens. At gøre testen grøn er alt, hvad der betyder noget.

I refactoring rydder du det rod du lige har lavet. Nu skal du først se, om den ændring, du lige har lavet, er den slags toppen mest i listen Transformation Priority, og hvis der er nogen kodeduplikation, kan du højst sandsynligt fjerne det ved at anvende et designpatter.

Endelig forbedrer du læsbarheden ved at omdøbe identifikatorer og udtrække magic numbers og / eller bogstaver til konstanter.


Det er ikke rødrefaktor, det er rødgrøn-refactor. - Rob Kinyon

Tak for at pege på dette.

Så det er den green fase, hvor du skriver den real code

I den red fase skriver du executable specification ...

2 comments
Rob Kinyon 07/27/2017
Det er ikke rødrefaktor, det er rødgrøn-refactor. Den "røde" er at du tager din testsuite fra grønt (alle testpasninger) til rødt (en test fejler). Den "grønne" er, hvor du slidt tager din testsuite fra rødt (en test fejler) til grøn (alle testpas). "Refactor" er hvor du tager din kode og gør det smuk, samtidig med at alle test forbi.
Timothy Truckle 07/27/2017
@RobKinyon Tak, opdateret svaret.

Robert Andrzejuk 07/27/2017.

Du skriver Real Code hele tiden.

Ved hvert trin skriver du kode for at opfylde de betingelser, som din kode vil tilfredsstille for fremtidige opkald til din kode (som muligvis er dig eller ej ...).

Du tror, ​​du skriver ikke brugbar ( real ) kode, for i et øjeblik kan du refactor det ud.

Kode-Refactoring er processen med at omstrukturere eksisterende computer kode-ændre factoring-uden at ændre sin eksterne adfærd.

Hvad det betyder er, at selvom du ændrer koden, bliver betingelserne koden satisificeret, uændret. Og de checks ( tests ), du har implementeret for at bekræfte din kode, er allerede der for at kontrollere, om dine ændringer har ændret noget. Så koden du skrev hele tiden er derinde, bare på en anden måde.

En anden grund Du tror måske, at det ikke er rigtig kode, det er, at du laver eksempler, hvor slutprogrammet allerede kan tilskrives dig. Dette er meget godt, som det viser Du har viden om det domain du programmerer i.
Men mange gange programmerere er i et domain som er new , unknown for dem. De ved ikke, hvad slutresultatet vil være, og TDD er en technique til at skrive programmer trin for trin og dokumentere vores knowledge om, hvordan dette system skal fungere og verificere, at vores kode fungerer på den måde.

Da jeg læste The Book (*) på TDD, var det vigtigste for mig, at listen var: TODO. Det viste mig, at TDD også er en teknik til at hjælpe udviklere med at fokusere på én ting af gangen. Så dette er også et svar på dit spørgsmål om How much Real code to write ? Jeg vil sige nok kode til at fokusere på 1 ting ad gangen.

(*) "Testdrevet udvikling: Ved eksempel" af Kent Beck

1 comments
2 Robert Andrzejuk 07/27/2017
"Testdrevet udvikling: Ved eksempel" af Kent Beck

Zenilogix 07/31/2017.

Du skriver ikke kode for at få dine tests fejlet.

Du skriver dine tests for at definere, hvilken succes der skal se ud, hvilket alle i første omgang skulle fejle, fordi du endnu ikke har skrevet koden, der vil passere.

Hele punktet om at skrive initialt fejlagtige tests er at gøre to ting:

  1. Dæk alle tilfælde - alle nominelle tilfælde, alle kantsager mv.
  2. Valider dine test. Hvis du kun ser dem, passerer, hvordan kan du være sikker på, at de pålideligt vil rapportere en fejl, når man opstår?

Baggrunden for rødgrønrefaktor er, at det at skrive de korrekte tests først giver dig selvtillid til at vide, at koden du skrev for at bestå testene er korrekt, og giver dig mulighed for at refactor med den tillid, at dine test vil informere dig så snart som noget går i stykker, så du kan straks gå tilbage og rette det.

I min egen erfaring (C # /. NET) er ren test først en smule et uopnåeligt ideal, fordi du ikke kan sammensætte et kald til en metode, som endnu ikke eksisterer. Så "test først" handler først og fremmest om kodning af grænseflader og stubbende implementeringer først og derefter skrivning af prøver mod stubberne (som i første omgang vil mislykkes), indtil stubberne er korrekt fleshed ud. Jeg skriver aldrig "failing code", bare ved at bygge ud af stubber.


Zan Lynx 07/27/2017.

Jeg tror, ​​du kan være forvirret mellem enhedsprøver og integrationstest. Jeg tror, ​​at der også kan være accepttest, men det afhænger af din proces.

Når du har testet alle de små "enheder", så tester du dem alle sammen, eller "integreret". Det er normalt et helt program eller bibliotek.

I kode, som jeg har skrevet integrationstestene, er et bibliotek med forskellige testprogrammer, der læser data og føder det til biblioteket, så kontroller resultaterne. Så gør jeg det med tråde. Så gør jeg det med tråde og gaffel () i midten. Så kører jeg det og dræber -9 efter 2 sekunder, så starter jeg det og tjekker genoprettelsesfunktionen. Jeg fuzz det. Jeg torturerer det på alle måder.

Alt dette er også test, men jeg har ikke en ret rød / grøn display til resultaterne. Det lykkes enten, eller jeg graver gennem et par tusind linjer med fejlkode for at finde ud af hvorfor.

Det er her du tester den "rigtige kode".

Og jeg tænkte bare på dette, men måske ved du ikke, hvornår du skal lave skrive enhedsprøver. Du er færdig med at skrive enhedsprøver, når dine tests udøver alt, hvad du har angivet det skal gøre. Nogle gange kan du tabe det blandt alle fejlhåndtering og kantsager, så du vil måske gerne lave en god testgruppe af glade sti test, der simpelthen går lige gennem specifikationerne.

1 comments
Peter Mortensen 07/27/2017
(dens = besiddende, det er = "det er" eller "det har". Se for eksempel How to Use Its and It's .)

user3791372 07/27/2017.

Som svar på titlen på spørgsmålet: "Hvornår skriver du den" rigtige "kode i TDD?", Svaret er: "næsten aldrig" eller "meget langsomt".

Du lyder som en elev, så jeg vil svare som om at rådgive en elev.

Du skal lære mange kodende 'teorier' og 'teknikker'. De er gode til at passere tiden på overpriced studerende kurser, men af ​​meget lidt fordel for dig, at du ikke kunne læse i en bog om halvdelen af ​​tiden.

Arbejdet med en koder er udelukkende at producere kode. Kode, der virker rigtig godt. Derfor planlægger du koderen koden i dit sind, på papir, i en passende ansøgning mv., Og du planlægger at arbejde omkring eventuelle fejl / huller på forhånd ved at tænke logisk og sideværts før kodning.

Men du skal vide, hvordan du kan bryde din ansøgning for at kunne designe anstændig kode. For eksempel, hvis du ikke vidste om Little Bobby Table (xkcd 327), vil du sandsynligvis ikke rense dine input før du arbejder med databasen, så du ville ikke være i stand til at sikre dine data omkring dette koncept.

TDD er bare en arbejdsgang designet til at minimere fejlene i din kode ved at lave test af, hvad der kunne gå galt, før du kode din ansøgning, fordi kodning kan blive eksponentielt vanskeligere, jo flere kode du introducerer, og du glemmer bugs, som du engang troede på. Når du tror, ​​at du er færdig med din ansøgning, kører du test og boom, forhåbentlig bliver bugs fanget med dine test.

TDD er ikke - som nogle tror på - at skrive en test, få den til at passere med minimal kode, skrive en anden test, få det forbi med minimal kode osv. I stedet er det en måde at hjælpe dig med at kode med tryghed. Dette ide om kontinuerlig refactoring kode for at gøre det arbejde med test er idiotisk, men det er et godt koncept blandt eleverne, fordi det får dem til at føle sig godt, når de tilføjer en ny funktion, og de lærer stadig at kode ...

Vær venlig at ikke falde ned i denne fælde og se din rolle som kodning for hvad det er - jobbet af en koder er udelukkende til at producere kode. Kode, der virker rigtig godt. Husk nu, at du vil være døgnet som professionel koder, og din klient vil ikke være ligeglad, hvis du skrev 100.000 påstande eller 0. De vil bare have kode, der virker. Virkelig godt, faktisk.

5 comments
3 johnny 07/25/2017
Jeg er ikke engang tæt på en elev, men jeg læser og forsøger at anvende gode teknikker og være professionelle. Så i den forstand er jeg en "studerende". Jeg spørger bare meget grundlæggende spørgsmål, for det er sådan jeg er. Jeg kan godt lide at vide præcis, hvorfor jeg gør hvad jeg laver. Hjertet i sagen. Hvis jeg ikke får det, kan jeg ikke lide det og begynde at stille spørgsmål. Jeg skal vide hvorfor, hvis jeg skal bruge den. TDD virker intuitivt godt på nogle måder som at vide, hvad du har brug for til at skabe og tænke tingene igennem, men implementeringen var svært at forstå. Jeg tror, ​​jeg har en bedre forståelse nu.
4 Sean Burton 07/27/2017
Det er TDD's regler. Du er fri til at skrive kode, men du vil have det, men hvis du ikke følger disse tre regler, har du ikke TDD.
2 user3791372 07/27/2017
"Regler" for en person? TDD er et forslag til at hjælpe dig med at kode, ikke en religion. Det er ked af at se så mange mennesker overholde en ide så analt. Selv TDD's oprindelse er kontroversiel.
2 Alex 07/28/2017
@ user3791372 TDD er en meget streng og klart defineret proces. Selvom mange tror, ​​at det bare betyder "Gør nogle test, når du programmerer", er det ikke. Lad os prøve at ikke blande betingelser her, dette spørgsmål handler om processen TDD, ikke generelle test.

HighResolutionMusic.com - Download Hi-Res Songs

1 The Chainsmokers

Beach House flac

The Chainsmokers. 2018. Writer: Andrew Taggart.
2 (G)I-DLE

POP/STARS flac

(G)I-DLE. 2018. Writer: Riot Music Team;Harloe.
3 Anne-Marie

Rewrite The Stars flac

Anne-Marie. 2018. Writer: Benj Pasek;Justin Paul.
4 Ariana Grande

​Thank U, Next flac

Ariana Grande. 2018. Writer: Crazy Mike;Scootie;Victoria Monét;Tayla Parx;TBHits;Ariana Grande.
5 Clean Bandit

Baby flac

Clean Bandit. 2018. Writer: Jack Patterson;Kamille;Jason Evigan;Matthew Knott;Marina;Luis Fonsi.
6 BTS

Waste It On Me flac

BTS. 2018. Writer: Steve Aoki;Jeff Halavacs;Ryan Ogren;Michael Gazzo;Nate Cyphert;Sean Foreman;RM.
7 Imagine Dragons

Bad Liar flac

Imagine Dragons. 2018. Writer: Jorgen Odegard;Daniel Platzman;Ben McKee;Wayne Sermon;Aja Volkman;Dan Reynolds.
8 Nicki Minaj

No Candle No Light flac

Nicki Minaj. 2018. Writer: Denisia “Blu June” Andrews;Kathryn Ostenberg;Brittany "Chi" Coney;Brian Lee;TJ Routon;Tushar Apte;ZAYN;Nicki Minaj.
9 Brooks

Limbo flac

Brooks. 2018.
10 BlackPink

Kiss And Make Up flac

BlackPink. 2018. Writer: Soke;Kny Factory;Billboard;Chelcee Grimes;Teddy Park;Marc Vincent;Dua Lipa.
11 Diplo

Close To Me flac

Diplo. 2018. Writer: Ellie Goulding;Savan Kotecha;Peter Svensson;Ilya;Swae Lee;Diplo.
12 Rita Ora

Velvet Rope flac

Rita Ora. 2018.
13 Fitz And The Tantrums

HandClap flac

Fitz And The Tantrums. 2017. Writer: Fitz And The Tantrums;Eric Frederic;Sam Hollander.
14 Little Mix

Woman Like Me flac

Little Mix. 2018. Writer: Nicki Minaj;Steve Mac;Ed Sheeran;Jess Glynne.
15 Billie Eilish

When The Party's Over flac

Billie Eilish. 2018. Writer: Billie Eilish;FINNEAS.
16 K-391

Mystery flac

K-391. 2018.
17 Cher Lloyd

None Of My Business flac

Cher Lloyd. 2018. Writer: ​iamBADDLUCK;Alexsej Vlasenko;Kate Morgan;Henrik Meinke;Jonas Kalisch;Jeremy Chacon.
18 Backstreet Boys

Chances flac

Backstreet Boys. 2018.
19 Lil Pump

Arms Around You flac

Lil Pump. 2018. Writer: Rio Santana;Lil Pump;Edgar Barrera;Mally Mall;Jon Fx;Skrillex;Maluma;Swae Lee;XXXTENTACION.
20 Kelly Clarkson

Never Enough flac

Kelly Clarkson. 2018. Writer: Benj Pasek;Justin Paul.

Related questions

Hot questions

Language

Popular Tags