Paras vastaus
Työskentelen tällä hetkellä AutoTraderissa, joka tekee mielestäni tämän hyvin.
Istumme sinut vain kannettavan tietokoneen eteen, isommalla näytöllä ja näppäimistöllä / hiirellä, pariksi yhden vanhemman kehittäjämme kanssa ja toisen vanhemman kehittäjän tarkkailemana.
Se on melko hauskaa kaikki estämällä tavalliset haastatteluhermot ja se, että tapaat uusia ihmisiä. Mutta varmasti, kun olen parisi, yritän saada vähän ystävällistä yhteyttä, saada sinut tuntemaan olosi tervetulleeksi ja niin edelleen. Aivan kuten normaalisti. Juurtun itse asiassa sinun onnistumiseksi.
Saat puolen sivun ongelman kuvauksen yksinkertaisesta tehtävästä. Ja sitten teet vähän pariohjelmointia.
Havaittuja ja pisteytettyjä asioita on useita:
- Kirjoitatko testit ensin? Koodin jälkeen? Ei koskaan?
- Käytätkö testejä ajatellaksesi suunnittelua?
- Nimetkö asiat selkeästi?
- Kannatatko OOP: ta, menettelyjen ohjelmointia – vai vain yhtä valtava tehtävä?
- Oletko vuorovaikutuksessa parin kanssa hyvin? Vai edes ollenkaan?
- Selitätkö ajattelusi mennessäsi ja kutsutko parin osallistumaan? Tai istu hiljaisuudessa?
- Käytätkö Java-palvelussa vakio-palveluita, kuten Collections? Jos ei, niin mitä teet?
- Käytätkö valitsemaasi IDE: tä hyvin?
- Jaatko ongelman hyvin? Huonosti? Ei lainkaan?
Jos pystyt tekemään Java-, TDD- ja / tai suunnittelun testattavaksi yksikköä varten ja näyttävät kohtuullisen miellyttävältä lajitelmalta, sinulla on yleensä pisteet.
Tämä testi ei koske outoa kieliominaisuuksia, outoa algoritmitietoa tai edes ongelman viimeistelyä.
Kyse on vain siitä, miten käytät näitä ansioluettelosi kirjoittamiasi asioita tosielämässä.
Nautit siitä todella. Se antaa kaikille oikeudenmukaisen kuvan ehdokkaan sijainnista.
Se huuhtelee häikäilemättömästi myös valheelliset CV-väitteet.
Oletetaan, että teet TDD: tä? Etkö tiedä mitä väittää tarkoittaa? Ohhoh. Oletetaan, että olet oppinut OOP: n? Kaikki koodi, joka ei toimi, on samalla menetelmällä kuin toimittamamme yksikkötesti? Voi rakas.
(Ja kyllä, se todella tapahtui).
Minulle se on ollut silmänavaus tämän prosessin molemmilla puolilla.
Vastaus
TDD on työkalu. Mikä vikaa, on TDD: n käsitteleminen uskonnona.
TDD tehdään tyypillisesti yksikkötesteillä: Pienten osien tai toimintojen (”yksiköt”) testit ) koodisi. Yksikkötestien on tarkoitus suorittaa nopeasti , joten yleensä pilkkaat kaikki ulkoiset palveluriippuvuudet ja varmistat vain, että itse koodia testataan.
valtava elefantti huoneessa -ongelma on, että joskus pilkkaamasi ulkoiset palvelut sisältävät suurimman osan toiminnon logiikasta. Jos yksikkösi nappaa kohteen tietokannasta kyselyn avulla ja palauttaa sen, pilkkaa , tämä vuorovaikutus on 100\% hyödytön paitsi tyyppitarkastuksen korvikkeena.
Haluan sanoa sen jälleen eri tavalla: Niin sanotut ”ajatusjohtajat” ”Jotka saarnaavat TDD: n evankeliumia, saarnaavat usein myös dynaamisten kielten evankeliumia. Joten kielet, joita he kertovat sinulle, ovat paljon tuottavampia todellakin vaativat paljon enemmän työtä testattavaksi ja usein kirjoittamaan testit uudelleen, kun sinun täytyy refraktoida.
Kirjoita koodi turvallisemmalla kielellä, kuten C #, Java tai TypeScript, niin et Ei tarvitse huolehtia siitä, että tyypit ovat edelleen kelvollisia. Staattisten kielten käytöstä on tonnia todellisia etuja sen lisäksi, että sinun ei tarvitse kirjoittaa testejä, jotka eivät todellakaan testaa mitään.
Joten mitä tarkoitan testeillä ”ei testaa mitään”? Oletetaan, että sinulla on toiminto, joka tekee SQL-kyselyn tietokantaan. Sen on tarkoitus etsiä tietyn kentän suodattamia kohteita. Nopean yksikötestin kirjoittamiseksi pilkataan SQL-kyselyä. Ellei mallikirjastosi todellakaan voi simuloida kaikkia esimerkkitietojoukkoja käsittelevän PostgreSQL: n logiikkaa, toimintosi todellista ydintä logiikkaa ei testata lainkaan ; Ainoat perusteelliset testit, jotka voit kirjoittaa logiikan vahvistamiseksi, vahvistavat vain, että pilkkaasi palauttivat asianmukaisia vastauksia.
Näen usein pilkkuja, jotka yksinkertaisesti ”tarkista, että tietokantaan soitettiin oikea määrä kertoja”. Silloin saat 100\% koodikattavuutesi! Hienoa, luku ei-teknisille johtajille, mikä ei tarkoita käytännössä mitään! Mene joukkueen harhaanjohtaviin tilastoihin!
Ei, tarvitset järjestelmätestejä tai integraatio / E2E-testejä vahvistaaksesi, että koko järjestelmäsi on toimi. Ei vain yksikkötestejä, vaan testejä, jotka eivät pilkkaa tietokannan puheluja, vaan suorittavat ne.Ja kun testipaketin on pystyttävä seisomaan todellinen testitietokanta, tyhjentämään se ja siirtämään se testien välillä, se tekee TDD: stä käytännössä epäkäytännöllisen; se on liian hidas.
Kirjoita siis ensin koodi ja kirjoita sitten E2E -testi ja varmista, että se saa oikean tuloksen. Heck, voit käyttää testipakettien tilannekuvan ominaisuutta, kuten Jesthttps: //jestjs.io/docs/en/snapshot-testing, vain vahvistaaksesi, että vastaus ei muutu; tarkastele sitä kerran varmistaaksesi, että se on oikein, ja sitten kun olet kertonut Jestille, että se on oikein, se vahvistaa, että se pysyy samana tulevissa ajoissa! Sovellusliittymiä voidaan testata ja testit voidaan päivittää melkein automatisoidusti!
Joten jos jätät huomiotta TDD-uskollisten raivot, saat työnne tehtyä kaksi kertaa nopeammin, koska et tarvitse odottaa 10 minuuttia (tai kauemmin! Olen nähnyt testipaketin, joka kesti yli tunnin …) koko E2E-paketin suorittamiseen, jotta testi epäonnistui ennen kuin aloitat koodisi kirjoittamisen.
Lisäksi käyttöliittymän testaaminen ollenkaan , kuten Moray Taylorin vastauksessa todettiin, on epäkäytännöllinen monissa olosuhteissa. Joitakin E2E-testejä voidaan soveltaa käyttöliittymään, mutta pääosin sijoitetun pääoman tuotto näyttää yleensä olevan sen arvoista.
Siitä huolimatta työskentelin -grafiikkakirjastolla kerran, jota käytti yli sata videopeliä, ja kirjoitin E2E-testin paketti sen vahvistamiseksi, että muutos kirjaston sisäisessä logiikassa ei riko mitään hämärää peliä, jota en ole koskaan edes nähnyt. Kirjastot ansaitsevat aina perusteellisempia testejä. Mutta yhden sovelluksen käyttöliittymälle E2E-testaus ei ole koskaan järkevää kokemuksellani.