Milloin kirjoitat "oikean" koodin TDD: ssä?

johnny 08/19/2017. 11 answers, 20.464 views
tdd

Kaikki esimerkit, jotka olen lukenut ja nähnyt koulutusvideot, ovat yksinkertaisia ​​esimerkkejä. Mutta mitä en näe, miten teen "oikean" koodin vihreän jälkeen. Onko tämä "Refactor" osa?

Jos minulla on melko monimutkainen objekti monimutkaisella menetelmällä, kirjoitan testiäni ja vähimmäisarvon, jotta se kuluu (kun se ensin epäonnistuu, punainen). Milloin palaan ja kirjoitan oikean koodin? Ja kuinka paljon oikeaa koodia kirjoitan ennen kuin testaan ​​uudelleen? Oletan, että viimeinen on enemmän intuitiota.

Edit: Kiitos kaikille, jotka vastasivat. Kaikki vastauksesi auttoivat minua äärettömän paljon. Näyttäisi olevan erilaisia ​​ideoita siitä, mitä kysyin tai hämmentyin, ja ehkä on, mutta kysyin, että minulla oli hakemus koulun rakentamisesta.

Minun suunnittelussani on arkkitehtuuri, jonka haluan aloittaa, User Stories, niin jne. Täältä otan nämä Käyttäjätarinat ja luon testi User Story -työkalun testaamiseen. Käyttäjä sanoo, meillä on ihmisiä ilmoittautumaan kouluun ja maksamaan rekisteröintimaksut. Joten ajattelen tapa, jolla tämä epäonnistuu. Suunnittelemalla näin luokka X (ehkä opiskelija), joka epäonnistuu. Sitten luodaan "Student" -luokka. Ehkä "koulu" en tiedä.

Joka tapauksessa TD Design pakottaa minut ajattelemaan tarinan läpi. Jos voin tehdä testin epäonnistumisen, tiedän, miksi se epäonnistuu, mutta tämä edellyttää, että voin tehdä sen läpi. Kyse on suunnittelusta.

Pidän tätä ajatellessani Recursion. Rekursiota ei ole vaikea käsite. Voi olla vaikeampaa seurata sitä päällesi, mutta todellisuudessa vaikein osa tietää, kun rekursiota "murtuu", kun lopetetaan (tietenkin minun mielipiteeni). Joten minun täytyy miettiä, mitä pysähtyy Recursion ensin. Se on vain epätäydellinen analogia, ja se olettaa, että jokainen rekursiivinen iteraatio on "passi". Jälleen vain lausunto.

Toteutuksessa, Koulu on vaikeampi nähdä. Numeeriset ja pankkitoiminnot ovat "helppoa" siinä mielessä, että voit käyttää yksinkertaisia ​​aritmeettisia. Näen a + b ja paluu 0 jne. Ihmisjärjestelmässä minun on ajateltava kovemmin sitä, miten se implement . Minulla on käsitys epäonnistumisesta, passista, refactorista (lähinnä tutkimuksen ja tämän kysymyksen vuoksi).

Mitä en tiedä perustuu mielestäni kokemattomuuteen. En tiedä, miten epäonnistuisit allekirjoittamaan uuden opiskelijan. En tiedä, miten epäonnistuu, että joku kirjoittaa sukunimen ja tallennetaan tietokantaan. Tiedän, miten tehdä yksinkertaisen matematiikan + 1, mutta henkilöiden kaltaisilla yksiköillä en tiedä, testataanko vain tietokannan ainutkertaisen ID: n tai jotain muuta, kun joku kirjoittaa nimensä tietokanta tai molemmat tai ei.

Tai ehkä tämä osoittaa, että olen edelleen hämmentynyt.

5 Comments
187 hobbs 07/25/2017
Kun TDD ihmiset menevät kotiin yöksi.
14 Goyo 07/25/2017
Miksi luulet, että kirjoittamasi koodi ei ole todellinen?
2 johnny 07/26/2017
@RubberDuck Enemmän kuin muut vastaukset. Olen varma, että viittaan siihen pian. Se on edelleen eräänlainen ulkomaalainen, mutta en aio luopua siitä. Mitä sanoitte, oli järkevää. Yritän vain tehdä asiasta omaa asiaani tai säännöllistä liiketoimintasovellusta. Ehkä luettelojärjestelmä tai vastaava. Minun täytyy pohtia sitä. Olen kuitenkin kiitollinen ajastasi. Kiitos.
1 Edmund Reed 07/26/2017
Vastaukset ovat jo osuneet kynsiin päähän, mutta niin kauan kuin kaikki testit ovat kulkeneet ja et tarvitse uusia testejä / toimintoja, voidaan olettaa, että koodi on valmis, bar linting.
3 Borjab 07/26/2017
Kysymyksessä on kysymys, joka saattaa olla ongelmallista "Minulla on melko monimutkainen objekti monimutkaisella menetelmällä". TDD: ssä kirjoitat testit ensin niin, että aloitat melko yksinkertaisella koodilla. Tämä pakottaa sinut koodataksesi testiystävällisen rakenteen, joka on modulaarinen. Niin monimutkainen käyttäytyminen syntyy yhdistämällä yksinkertaisempia esineitä. Jos päättyy melko monimutkaisella esineellä tai menetelmällä, silloin kun uudelleenaktivoidaan

11 Answers


RubberDuck 07/27/2017.

Jos minulla on melko monimutkainen objekti monimutkaisella menetelmällä, kirjoitan testiäni ja vähimmäisarvon, jotta se kuluu (kun se ensin epäonnistuu, punainen). Milloin palaan ja kirjoitan oikean koodin? Ja kuinka paljon oikeaa koodia kirjoitan ennen kuin testaan ​​uudelleen? Oletan, että viimeinen on enemmän intuitiota.

Et "palaa" ja kirjoita "oikea koodi". Se on kaikki todellinen koodi. Mitä teet, palaa ja lisää uusi testi, joka forces sinua change koodisi uuden testin läpäisemiseksi.

Mitä koodia kirjoittaessasi kirjoitat ennen uudelleen testaamista? Ei mitään. Sinä kirjoitat zero ilman epäonnistuvaa testiä, joka forces sinut kirjoittamaan enemmän koodia.

Huomaa kuvio?

Käy läpi (toinen) yksinkertainen esimerkki toivoen, että se auttaa.

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

Helppo reipas.

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

Ei mitä sinä kutsuisit oikeaksi koodiksi, eikö? Lisätään testi, joka pakottaa muutoksen.

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

Voisimme tehdä jotain typerää, if n == 1 , mutta ohitamme terveellistä ratkaisua.

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

Viileä. Tämä toimii kaikille ei-FizzBuzz-numeroille. Mikä on seuraava panos, joka pakottaa tuotantokoodin muuttumaan?

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

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

Ja uudelleen. Kirjoita testi, joka ei vielä kulje.

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

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

Ja nyt olemme kattaa kaikki kolme kertaa (jotka eivät ole myöskään viiden kerran, huomaamme sen ja tulevat takaisin).

Emme ole vielä kirjoittaneet testiä "Buzz", joten kirjoita se.

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

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

Ja vielä tiedämme, että on olemassa toinen asia, jota meidän on käsiteltävä.

 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();
} 

Ja nyt voimme käsitellä kaikki 5: n kerrannaiset, jotka eivät ole myöskään 3: n kerrannaisia.

Tähän asti olemme jättäneet refactoring-vaiheen huomiotta, mutta näen joitakin päällekkäisyyksiä. Puhdista se nyt.

 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();
} 

Viileä. Nyt olemme poistaneet päällekkäisyyksien ja luoneet hyvin nimetyn toiminnon. Mikä on seuraava testi, jonka voimme kirjoittaa, pakottaa meidät vaihtamaan koodia? No, olemme välttäneet tapauksen, jossa numero on jaollinen molemmilla 3: lla ja 5: llä. Kirjoita nyt.

 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();
} 

Testit kuluvat, mutta meillä on enemmän päällekkäisyyksiä. Meillä on vaihtoehtoja, mutta aion käyttää "Extract Local Variable" muutama kerta, jotta emme reagoineet uudelleenkirjoittamisen sijaan.

 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();
} 

Ja olemme peittäneet kaiken kohtuullisen panoksen, mutta entä unreasonable panokset? Mitä tapahtuu, jos välitetään 0 tai negatiivinen? Kirjoita kyseiset testitapaukset.

 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();
} 

Onko tämä alkanut näyttää "oikeaksi koodiksi" vielä? Vielä tärkeämpää on, milloin se lopetti "epärealistisen koodin" ja siirtymisen olevan "todellinen"? Se on jotain miettimään ...

Joten pystyin tekemään tämän yksinkertaisesti etsimällä testiä, jota tiesin, ei kulje jokaisessa vaiheessa, mutta minulla on ollut paljon käytäntöjä. Kun olen töissä, asiat eivät ole koskaan yksinkertaisia, enkä välttämättä aina tiedä, mitä testi pakottaa muutoksen. Joskus kirjoitan testiä ja yllätyin siitä, että se on jo ohittanut! Suosittelen, että saat tapana luoda "testilista" ennen kuin aloitat. Tämä testi-luettelo sisältää kaikki "mielenkiintoiset" panokset, joista voit ajatella. Et välttämättä käytä niitä kaikkia, ja todennäköisesti lisäät tapauksia mennessasi, mutta tämä luettelo toimii etenemissuunnitelmana. FizzBuzzin testilistani näyttää jotain tällaista.

  • negatiivinen
  • Nolla
  • Yksi
  • Kaksi
  • Kolme
  • Neljä
  • Viisi
  • Kuusi (ei-triviaalinen 3-kertainen)
  • Yhdeksän (3 neliömetriä)
  • Kymmenen (ei-triviaali moninkertainen 5: stä)
  • 15 (moninkertainen 3 & 5)
  • 30 (ei-triviaalinen moninkertainen 3 ja 5)
5 comments
3 maple_shaft♦ 07/27/2017
Huomautuksia ei ole laajennettuun keskusteluun; tämä keskustelu on siirretty keskusteluun .
40 GManNickG 07/27/2017
Ellei täysin ymmärrä tätä vastausta: "Voisimme tehdä jotain typerää, jos n == 1, mutta ohitamme terveen ratkaisun." - koko asia oli typerä. Jos tiedät etupuolen haluat toiminnon, joka <spec>, kirjoittaa testejä <spec> ja ohittaa osan, jossa kirjoitat versioita, jotka ilmeisesti eivät toimi <spec>. Jos löydät virheen <spec>, varmista sitten: kirjoita testi ensin varmistaaksesi, että voit käyttää sitä ennen korjausta ja tarkkailla testikortteja korjauksen jälkeen. Mutta ei ole tarpeen torjua kaikkia näitä välivaiheita.
15 user3791372 07/28/2017
Huomautukset, jotka osoittavat tämän vastauksen ja TDD: n yleiset puutteet, on siirretty keskusteluun. Jos aiot harkita TDD: n käyttöä, lue "chat". Valitettavasti "laatu" kommentit ovat nyt piilossa joukossa chat-keskustelu tulevien opiskelijoiden lukea.
nbro 07/28/2017
Tarkoitan tarkemmin tämän "testilistan" sisältöä, jos haluat parantaa tätä vastausta. Haluan eksplisiittisesti puhua "raja-arvoista" ja "luokkien jakamisesta".
2 hvd 07/30/2017
@GManNickG Uskon, että asia on saada oikea määrä testejä. Testien kirjoittaminen etukäteen tekee helpoksi jättää huomiotta, mitä erikoistapauksia on testattava, mikä johtaa tilanteisiin, joita ei ole katettu riittävästi testeissä tai olennaisesti samassa tilanteessa, joka on epäilemättä katettu kuormituksia testissä. Jos voit tehdä sen ilman näitä välivaiheita, hyvä! Kaikki eivät voi tehdä niin, mutta se on jotain, joka vie käytännön.

GenericJon 07/24/2017.

"Todellinen" koodi on koodi, jonka kirjoitat testin läpäisemiseksi. Really . Se on niin yksinkertaista.

Kun ihmiset puhuvat puhtaasta vähimmäisarvosta testin vihreyden tekemiseksi, se tarkoittaa vain sitä, että todellisen koodisi tulisi noudattaa YAGNI-periaatetta .

Ajatus refactor-vaiheesta on vain puhdistaa mitä olet kirjoittanut, kun olet tyytyväinen, että se täyttää vaatimukset.

Niin kauan kuin kirjoittamasi testit todella kattavat tuotteesi vaatimukset, kun ne kulkevat, koodi on valmis. Ajattele sitä, jos kaikki yrityksesi tarpeet ovat testit ja kaikki nämä testit ovat vihreitä, mitä muuta on kirjoitettava? (Okei, tosielämässä meillä ei yleensä ole täydellistä testin kattavuutta, mutta teoria on hyvä.)

5 comments
44 Derek Elkins 07/24/2017
Yksikkötestit eivät tosiasiassa voi kattaa tuotteidesi vaatimuksia jopa suhteellisen vähäpätöisiksi vaatimuksiksi. Parhaimmillaan ne näyttävät panos-tuoton tilan ja ajatus on, että (oikein) yleistää koko panos-tuoton tilaa. Tietenkin koodisi voi olla vain iso switch jokaisen testituloksen tapauksessa, joka läpäisee kaikki testit ja epäonnistuu mihinkään muuhun panokseen.
8 Taemyr 07/25/2017
@DerekElkins TDD valtuutti testejä, jotka eivät täyttäneet testejä. Yksikkökokeiden puuttuminen.
6 jonrsharpe 07/25/2017
@DerekElkins, siksi et vain kirjoita yksikkötestejä, ja myös miksi yleinen oletus on, että yrität tehdä jotain paitsi väärennöstä!
35 Derek Elkins 07/25/2017
@jonrsharpe Tämän logiikan avulla en koskaan kirjoita triviaaleja toteutuksia. Esimerkiksi FizBuzz-esimerkissä RubberDuckin vastauksessa (joka käyttää vain yksikkötestejä) ensimmäinen toteutus "vain väärennökset". Ymmärrys kysymyksestä on täsmälleen tämä diktaatio kirjoituskoodin välillä, jonka tiedät olevan epätäydellinen ja koodi, jonka uskot aidosti toteuttavan vaatimuksen, "todellisen koodin". Oma "iso switch " oli tarkoitettu loogiseksi äärimmäksi "kirjoittamalla vähäinen vähimmäisaika testien tekemiseksi vihreiksi". Katson OP: n kysymystä: missä TDD on periaate, joka välttää tämän suuren switch ?
2 Luaan 07/25/2017
@GenericJon Tämä on hieman liian optimistinen kokemuksessani :) Yksi on ihmisiä, jotka nauttivat mielettömästä toistuvasta työstä. He ovat onnellisempia jättimäisen kytkinlausuman kanssa kuin "monimutkainen päätöksenteko". Ja menettää tehtävänsä, he tarvitsevat joko jonkun, joka kutsuu heidät ulos tekniikasta (ja heillä on paremmat todisteet siitä, että he menettävät yrityksen mahdollisuuksia / rahaa!) Tai poikkeuksellisen huonosti. Kun olen huolehtinut monista tällaisista hankkeista, voin sanoa, että erittäin naiivia koodeja on helppo kestää vuosikymmeniä, kunhan se tekee asiakkaasta onnelliseksi (ja maksaa).

Carl Raymond 07/24/2017.

Lyhyt vastaus on se, että "todellinen koodi" on koodi, joka tekee testin läpäisevän. Jos voit tehdä testikorttisi muuta kuin todellista koodia, lisää testejä!

Olen samaa mieltä siitä, että paljon tutoriaaleja TDD: stä ovat yksinkertaisia. Se toimii heitä vastaan. Liian yksinkertainen testi menetelmäksi, joka esimerkiksi laskee 3 + 8, ei todellakaan voi muuta kuin laskea 3 + 8: ta ja verrata tulosta. Tämä tekee siitä näyttävän, että kopioit koodin kaikkialla, ja että testaus on hyödytöntä, virheellistä ylimääräistä työtä.

Kun testaat hyvää, se kertoo, miten rakentaa sovelluksesi ja miten kirjoitat koodisi. Jos sinulla on vaikeuksia saada järkeviä, hyödyllisiä testejä, sinun pitäisi luultavasti uudelleen harkita suunnittelua hieman. Hyvin suunniteltu järjestelmä on helppo testata - tarkoittaen järkeviä testejä on helppo ajatella ja toteuttaa.

Kun kirjoitat testit ensin, näet, etteivät ne onnistu, ja kirjoita sitten koodi, joka tekee niistä läpäisevän. Tämä on kuria varmistaa, että kaikilla koodillasi on vastaavia testejä. En seurata orjuutta tätä sääntöä koodauksen aikana. usein kirjoitan testejä sen jälkeen. Mutta testit ensin auttavat pitämään sinut rehellisenä. Joidenkin kokemusten perusteella huomaat, kun koodit itseäsi nurkkaan, vaikka et kirjoita ensin testejä.

4 comments
6 Steve Jessop 07/26/2017
Henkilökohtaisesti testi, jonka kirjoittaisin, olisi assertEqual(plus(3,8), 11) , ei assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) . Monimutkaisempia tapauksia varten etsit aina keinoa todistaa tulos oikein, other than dynaamisesti laskemalla oikean tuloksen testiin ja tarkistamalla tasa-arvo.
Steve Jessop 07/26/2017
Joten tämän esimerkin todella hölmöllä tavalla voit todistaa, että plus(3,8) on palauttanut oikean tuloksen vähentämällä 3 siitä, vähentämällä siitä kahdeksan ja tarkistamalla tulos 0: ksi. Tämä on niin ilmeistä joka vastaa assertEqual(plus(3,8), 3+8) , jotta se olisi vähän absurdia, mutta jos testattava koodi rakennuttaa jotain monimutkaisempaa kuin vain kokonaisluku, oikea lähestymistapa. Vaihtoehtoisesti jotain, jolla for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
... koska se välttää suuren pelon, joka on, että kun kirjoitat testiä, teemme saman virheen aiheesta "kuinka lisätä 10", jonka teimme live-koodissa. Joten testi huolellisesti välttää kirjoittamasta mitään koodia, joka lisää 10: a mihin tahansa, testiin, että plus() voi lisätä 10 asioita. Tietenkään emme vielä luota ohjelmointivirheiden vahvistettuihin alkuilmapiiriin.
3 Warbo 07/28/2017
Haluan vain huomauttaa, että vaikka kirjoitat testejä sen jälkeen, on silti hyvä nähdä, etteivät ne epäonnistu. löytää jonkin osan koodista, joka vaikuttaa ratkaisevalta sille, mitä olet työskennellyt, muokkaa sitä hieman (esim. korvaa + tai - tai mitä tahansa), suorita testit ja katsele niitä epäonnistuvan, kumota muutokset ja katsella niitä kulkemaan. Monesti olen tehnyt tämän, testi ei todellisuudessa epäonnistu, mikä tekee siitä pahempaa kuin hyödytön: ei vain se testaa mitään, se antaa minulle väärän luottamuksen, että jotain testataan!

Victor Cejudo 07/25/2017.

Joskus jotkin TDD: n esimerkit voivat olla harhaanjohtavia. Kuten muutkin ovat huomauttaneet aiemmin, kirjoittamasi koodi testien läpäisemiseksi on todellinen koodi.

Mutta älä usko, että todellinen koodi näyttää maagista - se on väärä. Tarvitset paremman käsityksen siitä, mitä haluat saavuttaa, ja sitten sinun on valittava testi vastaavasti alkaen helpoimmista tapauksista ja kulmakohdista.

Jos esimerkiksi haluat kirjoittaa lexerin, aloitat tyhjällä merkkijono, sitten joukko valkoisia välilyöntejä, sitten numeroa, numeroa, jota ympäröivät valkoiset tilat, sitten väärä numero jne. Nämä pienet muutokset johtavat sinuun oikea algoritmi, mutta et hypätä helpoimmasta tapauksesta erittäin monimutkaiseen asiaan, joka on valittu hämmentyneesti saadaksesi oikean koodin tehtyä.

Bob Martin selittää sen täydellisesti täällä .


CandiedOrange 07/25/2017.

Refactor-osa puhdistaa, kun olet väsynyt ja halua mennä kotiin.

Kun lisäät ominaisuutta, refactor-osa on se, mitä muutat ennen seuraavaa testiä. Voit koodata koodia uudelleen, jotta voit luoda tilaa uudelle ominaisuudelle. Teet tämän, kun know mikä uusi ominaisuus on. Ei, kun vain kuvitellaan sitä.

Tämä voi olla niin yksinkertainen kuin GreetImpl GreetWorld ennen kuin luot GreetMom luokka (lisäämällä testi) lisätäksesi ominaisuuden, joka tulostaa "Hi-äiti".


graeme 07/27/2017.

Mutta todellinen koodi ilmestyy TDD-vaiheen refactor vaiheessa. Eli koodi, joka pitäisi olla osa lopullista julkaisua.

Testit tulisi suorittaa joka kerta, kun teet muutoksen.

TDD: n elinkaaren motto olisi: PUNAINEN VIHREÄ REFAKTORI

RED : Kirjoita testit

GREEN : Tee rehellinen yritys saada toiminnallinen koodi, joka läpäisee testit mahdollisimman nopeasti: kaksoiskoodi, hämärästi nimetyt muuttujat korkeimpien tilausten hakkeiksi jne.

REFACTOR : Puhdista koodi ja nimeä muuttujat oikein. Kuivaa koodi.

5 comments
5 mcottle 07/25/2017
Tiedän, mitä sanot "Vihreä" -vaiheesta, mutta se tarkoittaa, että kovan johdotuksen paluuarvot testien suorittamiseksi saattavat olla sopivia. Kokemukseni mukaan "vihreä" pitäisi olla rehellinen yritys tehdä työkoodi vaatimuksen täyttämiseksi, se ei välttämättä ole täydellinen, mutta sen pitäisi olla täydellinen ja "shippable", kuten kehittäjä voi hallita ensimmäisellä passilla. Refactoring on luultavasti parasta tehdä jonkin ajan kuluttua, kun olet tehnyt enemmän kehitystä ja ensimmäisellä passilla olevat ongelmat tulevat selvemmiksi ja DRY: n mahdollisuudet esiin.
graeme 07/25/2017
@mcottle Pidän näitä kaikkia osa samaa tehtävää. tee se ja puhdista se. Lisätoimintatyöt olisi tehtävä ajan myötä osana muita tehtäviä.
1 Bryan Boettcher 07/25/2017
@mcottle: Saatat yllättäytyä, kuinka monta vain saatavana olevan arkiston toteutuksia voi olla karkotettuja arvoja koodibusseissa. :)
6 Kaz 07/25/2017
Miksi minä kirjoittaisin romu koodi ja puhdistan sen, kun voin kiertää mukavaa tuotannon laatukoodia melkein yhtä nopeasti kuin voin kirjoittaa? :)
1 Kaz 07/27/2017
@TimothyTruckle Mitä jos kestää 50 minuuttia löytää mahdollisimman yksinkertainen muutos, mutta vain 5 löytää toisen yksinkertaisimmaksi mahdolliseksi muutokseksi? Menisimme toisella yksinkertaisimmillaan tai etsimme yksinkertaisimpia?

Timothy Truckle 07/27/2017.

Milloin kirjoitat "oikean" koodin TDD: ssä?

red vaihe on paikka, jossa write koodia.

refactoring vaiheessa ensisijainen tavoite on delete koodi.

red vaiheessa teet mitään testin läpäisemiseksi as quick as possible ja at any cost . Sinä jätät täysin huomiotta sen, mitä olet koskaan kuullut hyvistä koodauskäytännöistä tai suunnittelukuvista. Testi vihreä on kaikkea tärkeää.

refactoring vaiheessa puhdistat juuri tekemäsi sekaan. Nyt tarkastelet ensin, jos juuri tekemäsi muutos on sellainen, joka on kaikkein eniten Transformation Priority -luettelossa ja jos koodin päällekkäisyyksiä on mahdollista poistaa todennäköisimmin soveltamalla mallipintaa.

Lopuksi parannat luettavuutta uudelleennimeämällä tunnisteet ja poimittelemalla magic numbers ja / tai kirjaimellisia merkkijonoja vakioksi.


Se ei ole punainen-refactor, se on punainen-vihreä-refactor. - Rob Kinyon

Kiitos, että osoitit tätä.

Joten se on green vaihe, jossa kirjoitat real code

red vaihe kirjoittaa executable specification ...

2 comments
Rob Kinyon 07/27/2017
Se ei ole punainen-refactor, se on punainen-vihreä-refactor. "Punainen" vie sinut testisovelluksestasi vihreältä (kaikki testit kulkevat) punaiseksi (yksi testi epäonnistuu). "Vihreä" on paikka, jossa kovaa viedä testisarjan punaisesta (yksi testi epäonnistuu) vihreään (kaikki testit kulkevat). "Refactor" on se, jossa otat koodisi ja tekee siitä melko pitämällä kaikki testit kulkevat.
Timothy Truckle 07/27/2017
@RobKinyon Kiitos, päivitti vastauksen.

Robert Andrzejuk 07/27/2017.

Olet kirjoittamassa Real Code koko ajan.

Kussakin vaiheessa kirjoitat koodia täyttämään edellytykset, jotka koodisi täyttävät koodisi tulevat soittajat (mikä voi olla Sinä tai ei ...).

Luulet, että et käytä hyödyllistä ( real ) koodia, koska hetken voit palauttaa sen.

Code-Refactoring on prosessi, jolla nykyiset tietokonekoodit muutetaan - factoringin muuttaminen - muuttamatta sen ulkoista käyttäytymistä.

Tämä tarkoittaa sitä, että vaikka olet muuttanut koodia, ehtoja, jotka koodi on hyväksytty, jäävät muuttumattomiksi. Ja tarkistukset, jotka olet suorittanut vahvistaaksesi koodisi, ovat jo olemassa, jotta voit tarkistaa, ovatko muutokset muuttaneet mitään. Joten koodi, jonka kirjoitit koko ajan, on siellä aivan eri tavalla.

Toinen syy Sinä saatat ajatella, että se ei ole oikea koodi, että teet esimerkkejä, joiden loppusuunnitelma voi jo olla sinä. Tämä on erittäin hyvä, koska se osoittaa, että sinulla on tietoa domain olet ohjelmoinnissa.
Mutta monta kertaa ohjelmoijat ovat domain joka on new , unknown heille. He eivät tiedä, mikä lopputulos on, ja TDD on technique kirjoittaa ohjelmia askel askeleelta, dokumentoimalla knowledge siitä, miten tämä järjestelmä toimii ja todistaa, että koodimme toimii tällä tavoin.

Kun luin kirja (*) TDD: stä, minulle tärkein ominaisuus, joka erottui, oli: TODO-luettelo. Se osoitti minulle, että TDD on myös tekniikka, joka auttaa kehittäjiä keskittymään yhteen asiaan kerrallaan. Joten tämä on myös vastaus kysymykseesi, How much Real code to write ? Haluan sanoa tarpeeksi koodia keskittyä 1 asia kerrallaan.

(*) "Testiradatut kehitys: esimerkki" Kent Beck

1 comments
2 Robert Andrzejuk 07/27/2017
"Test Driven Development: esimerkki" Kent Beck

Zenilogix 07/31/2017.

Et kirjoita koodia testiesi epäonnistumiseen.

Kirjoitat testit määrittelemään, millainen menestys näyttäisi, mistä kaikkien pitäisi aluksi epäonnistua, koska et ole vielä kirjoittanut koodia, joka kulkee.

Koko pisteen aluksi epäonnistuneiden testien kirjoittamisesta on kaksi asiaa:

  1. Suojele kaikki tapaukset - kaikki nimelliset tapaukset, kaikki reuna-asiat jne.
  2. Vahvista testit. Jos näet vain ne, jotka ovat kulkeneet läpi, miten voit olla varma, että ne raportoivat luotettavasti epäonnistumisesta, kun jokin tapahtuu?

Punavihreän refaktorin takana on, että kirjoittamalla oikeat testit antavat ensin luottamukselle tietää, että koodin, jonka kirjoitit testien läpäisemiseksi, on oikea, ja voit palauttaa luottamuksellisuuden, että testit ilmoittavat sinulle heti, kun jotain katkeaa, joten voit heti mennä takaisin ja korjata sen.

Omassa kokemuksessani (C # / .NET) puhdas testi ensimmäinen on hieman saavuttamaton ihanteellinen, koska et voi soittaa puhelua sellaiseen menetelmään, jota ei vielä ole olemassa. Niinpä "testaa ensin" on oikeastaan ​​koodaamalla rajapintoja ja stubbing toteutukset ensin, sitten kirjoittamalla testejä vastaan ​​tyhmät (joka aluksi epäonnistuu), kunnes tynkäsi on kunnolla ulos. En ole koskaan kirjoittamassa "epäonnistuneita koodeja", vain rakentamalla tynkäistä.


Zan Lynx 07/27/2017.

Luulen, että saatat hämmentyä yksikkötestien ja integraatiotestien välillä. Mielestäni voi olla myös hyväksymiskokeita, mutta se riippuu prosessista.

Kun olet testannut kaikki pienet "yksiköt", testaat ne kaikki koottuna tai "integroituina". Se on yleensä koko ohjelma tai kirjasto.

Koodissa, jonka olen kirjoittanut integraatiokokeissa, on kirjasto, jossa on erilaisia ​​testiohjelmia, jotka lukevat tietoja ja syötetään sen kirjastoon, tarkista tulokset. Sitten teen sen langoilla. Sitten teen sen langoilla ja haarukalla () keskellä. Sitten ajetaan ja tapetaan -9 2 sekunnin kuluttua, sitten käynnistän sen ja tarkistan sen palautustilasta. Minä sytytän sen. Minä kidutan sen kaikenlaisilla tavoilla.

Kaikki tämä on myös testaus, mutta minulla ei ole melko punaista / vihreää näyttöä tuloksista. Se joko onnistuu, tai kaivoin muutama tuhat riviä virhekoodia selvittääksesi miksi.

Siellä testataan "oikeaa koodia".

Ja ajattelin vain tätä, mutta ehkä et tiedä, milloin sinun pitäisi tehdä kirjoitusyksikkökokeita. Olet tehnyt kirjoitusyksikkötestit, kun testit suorittavat kaiken, mitä olet määrittänyt. Joskus voit menettää kaiken virheenkäsittelyn ja reuna-asioiden joukosta, joten saatat haluta tehdä mukava testiryhmä onnellisista polutesteistä, jotka menevät suoraan erittelyjen kautta.

1 comments
Peter Mortensen 07/27/2017
(sen = omistajuus, se = "se on" tai "se on". Katso esimerkiksi How to Use Its and It's .)

user3791372 07/27/2017.

Vastauksena kysymyksen otsikkoon: "Milloin kirjoitat" todellisen "koodin TDD: ssä? Vastaus on:" tuskin koskaan "tai" hyvin hitaasti ".

Sinä kuulostaa opiskelijalta, joten minä vastaan ​​kuin opettaa opiskelijaa.

Aiot oppia paljon koodausta "teorioista" ja "tekniikoista". Heidän on hyvä ohjata aika ylihinnoilla opiskelijakursseilla, mutta sinulle on hyvin vähän hyötyä, ettet voinut lukea kirjaa puolessa ajasta.

Kooderin työ on yksinomaan koodin tuottaminen. Koodi, joka toimii todella hyvin. Tästä syystä kooderi suunnittelee koodin mieltäsi, paperilla, sopivassa sovelluksessa jne. Ja aiot työskennellä mahdollisten puutteiden / reikien ympärille etukäteen ajattelemalla loogisesti ja sivuttain ennen koodausta.

Mutta sinun täytyy tietää, miten rikkoa sovelluksesi, jotta pystyt suunnittelemaan kunnolliset koodit. Jos et esimerkiksi tiedä Little Bobby Table -työkalusta (xkcd 327), et todennäköisesti puhdista aineistoasi ennen kuin työskentelet tietokannan kanssa, joten et pysty varmistamaan tietojasi tämän konseptin ympärillä.

TDD on vain työnkulku, joka on suunniteltu minimoimaan koodin virheet luomalla testit siitä, mikä voisi mennä pieleen, ennen kuin koodit sovellustasi, koska koodaus voi saada eksponentiaalisesti vaikeampaa, kun lisäät koodia ja unohdat virheitä, joita olet kerran ajatellut. Kun luulet, että olet suorittanut sovelluksesi, suoritat testit ja puomi, toivottavasti virheet jäävät testeihin.

TDD ei ole - kuten jotkut uskovat - kirjoittamaan testiä, saat sen ohittamaan minimaalisella koodilla, kirjoita toinen testi, siirrä se ohimennen pienellä koodilla jne. Sen sijaan se on tapa auttaa sinua koodata itsevarmasti. Tämä ihanteellinen jatkuva refactoring koodi, jotta se toimisi testeissä on idioottinen, mutta se on mukava konsepti opiskelijoiden keskuudessa, koska se tekee heistä tuntuu hyvältä, kun he lisäävät uuden ominaisuuden ja he oppivat edelleen koodaamaan ...

Älä laske tätä ansaan ja näe roolisi koodausta siitä, mikä se on - kooderin työ on yksinomaan koodin tuottaminen. Koodi, joka toimii todella hyvin. Muista, että olet kellonajan ammattikooderina, eikä asiakkaasi välitä, jos kirjoitit 100 000 väitettä tai 0. He vain haluavat koodin, joka toimii. Todella hyvin.

5 comments
3 johnny 07/25/2017
En ole edes lähellä oppilasta, mutta luen ja yritän soveltaa hyviä tekniikoita ja olla ammattilaisia. Joten siinä mielessä olen "opiskelija". Kysyn vain hyvin peruskysymyksiä, koska näin olen. Haluan tietää tarkalleen, miksi teen sen, mitä teen. Asian ydin. Jos en saa sitä, en pidä siitä ja aloita kysymyksiä. Minun täytyy tietää miksi, jos aiot käyttää sitä. TDD näyttää intuitiivisesti hyvältä jollain tavoin kuin tietäen, mitä tarvitset luoda ja ajattelemaan asioita, mutta toteutusta oli vaikea ymmärtää. Luulen, että minulla on parempi käsitys nyt.
4 Sean Burton 07/27/2017
Nämä ovat TDD: n sääntöjä. Voit kirjoittaa koodia haluamallasi tavalla, mutta jos et noudata näitä kolmea sääntöä, et käytä TDD: tä.
2 user3791372 07/27/2017
Yhden henkilön "säännöt"? TDD on ehdotus, joka auttaa koodia, ei uskontoa. On surullista nähdä, että monet ihmiset noudattavat ajatusta niin ankeasti. Jopa TDD: n alkuperä on kiistanalainen.
2 Alex 07/28/2017
@ user3791372 TDD on erittäin tiukka ja selkeästi määritelty prosessi. Vaikka monet ajattelevat, että tämä tarkoittaa vain "Tee joitain testejä ohjelmoidessasi", se ei ole. Yritetään olla sekoittamatta termejä täällä, tämä kysymys on prosessi TDD, ei yleinen testaus.

Related questions

Hot questions

Language

Popular Tags