Beste svaret
Jeg jobber for tiden for AutoTrader, som etter min mening gjør dette veldig bra.
Vi setter deg bare ned foran en bærbar PC, med en større skjerm og tastatur / mus, sammenkoblet med en av våre seniorutviklere, og observert av en annen seniorutvikler.
Det er ganske morsomt for alle, utenom de vanlige intervjunervene, og det faktum at du møter nye mennesker. Men absolutt, når jeg er paret ditt, prøver jeg å ha litt vennlig rapport, får deg til å føle deg velkommen og så videre. Akkurat som jeg normalt ville gjort. Jeg har faktisk rot for at du skal lykkes.
Du får en beskrivelse av en halv side av en enkel oppgave. Og så gjør du litt parprogrammering.
Det er flere ting observert og scoret:
- Skriver du tester først? Etter kode? Aldri?
- Bruker du tester for å tenke på designet?
- Navner du ting tydelig?
- Foretrekker du OOP, prosedyreprogrammering – eller bare en enorm funksjon?
- Samhandler du godt med paret? Eller til og med i det hele tatt?
- Forklarer du tankene dine mens du går, og inviterer paret til å bidra? Eller sitte i stillhet?
- Bruker du standard fasiliteter i Java, som Collections? Hvis ikke, hva gjør du?
- Bruker du IDE (som er ditt valg) bra?
- Deler du problemet godt opp? Dårlig? Ikke i det hele tatt?
Hvis du kan gjøre Java, TDD og / eller design for å bli enhetstestet, og virke som en rimelig personlig type, har du en tendens til å score høyt.
Denne testen handler ikke om rare språkfunksjonskunnskaper, eller rare algoritmekunnskaper, eller til og med etterbehandling av problemet.
Det handler om å se hvordan du bruker disse tingene du har skrevet på CVen din i det virkelige liv.
Du vil virkelig glede deg over det. Det gir alle et rettferdig bilde av hvor en kandidat er.
Det skyller nådeløst ut falske CV-påstander også.
Si du gjør TDD? Vet du ikke hva påstå betyr? Å kjære. Si at du har mestret OOP? All koden, som ikke fungerer, er på samme måte som enhetstesten vi leverte? Å kjære.
(Og ja, det skjedde virkelig).
For meg har det vært en øyeåpner å være på begge sider av denne prosessen.
Svar
TDD er et verktøy. Det som er galt er å behandle TDD som en religion.
TDD gjøres vanligvis med enhetstester: Tester av små deler eller funksjoner («enheter») ) av koden din. Enhetstestene skal kjøre raskt , slik at du generelt håner med eventuelle eksterne tjenesteavhengigheter og bare sørger for at selve koden testes.
Problemet med enorm-elefant-i-rommet med dette er at noen ganger inneholder de eksterne tjenestene du har spottet, mest av logikken til en funksjon. Hvis “enheten” tar tak i et element fra en database ved hjelp av et spørsmål og returnerer det, spottende er interaksjonen 100\% ubrukelig bortsett fra som en erstatning for typekontroll.
La meg si det igjen på en annen måte: De såkalte “tankelederne ”Som forkynner TDDs evangelium, forkynner ofte også evangeliet om dynamiske språk. Så språkene de forteller deg er så mye mer produktive krever faktisk mye mer arbeid for å teste, og ofte for å omskrive disse testene når du trenger å omformere.
Skriv koden på et tryggere språk som C #, Java eller TypeScript, så gjør du ikke Du trenger ikke å bekymre deg for å kontrollere at typene fremdeles er gyldige. Og det er tonn faktiske fordeler ved å bruke språk for statisk type i tillegg til at du ikke trenger å skrive tester som faktisk ikke tester noe.
Så hva mener jeg egentlig med testene «ikke å teste noe»? Si at du har en funksjon som lager et SQL-spørsmål mot databasen din. Det er ment å se etter gjenstander som er filtrert etter et bestemt felt. For å skrive en rask enhetstest, spotter du SQL-spørringen. Med mindre ditt hånebibliotek faktisk kan simulere all logikken til PostgreSQL som arbeider med et eksempeldatasett, blir den virkelige kjernen logikken av funksjonen din ikke testet i det hele tatt ; de eneste materielle testene du kunne skrive for å bekrefte logikken, ville bare validere at -spottene returnerte passende svar.
Jeg ser ofte spott som bare «bekreft at databasen ble kalt riktig antall ganger.» Det vil tross alt gi deg 100\% kodedekning! Flott, et tall å imponere de ikke-tekniske lederne som betyr absolutt ingenting i praksis! Go team Deceptive Statistics!
Nei, det du trenger er systemtester, eller integrasjon / E2E-tester, for å validere at hele systemet ditt er arbeider. Ikke bare enhetstester, men tester som ikke spotter samtalene til databasen, men utfører i stedet disse samtalene.Og når en testpakke trenger å stille opp en faktisk testdatabase, fjerne den og så den mellom testene, gjør TDD som praksis upraktisk; det er for sakte.
Så fortsett og skriv koden først, og skriv deretter E2E-testen din, og sørg for at den får riktig resultat. Pokker, du kan bruke øyeblikksbildefunksjonen til testserier som Jesthttps: //jestjs.io/docs/en/snapshot-testing for bare å validere at svaret ikke endres; se på det en gang for å sikre at det er riktig, og etter at du har fortalt Jest at det er riktig, vil det validere at det forblir det samme i fremtidige løp! API-er kan testes og oppdateres på en nesten automatisert måte!
Så hvis du ignorerer fabrikkene til TDD-troende, kan du gjøre arbeidet ditt dobbelt så raskt fordi du ikke trenger å vente i 10 minutter (eller lenger! Jeg har sett en testpakke som tok over en time …) for hele E2E-pakken å kjøre for å se testen mislykkes før du begynner å skrive koden.
I tillegg er det å teste UI i det hele tatt , som påpekt i Moray Taylor sitt svar, upraktisk under mange omstendigheter. Det er noe nivå av E2E-test som kan brukes på brukergrensesnittet, men for det meste virker avkastningen sjelden verdt det for det generelle tilfellet.
Når det er sagt, jobbet jeg med et grafikkbibliotek en gang som ble brukt av over hundre forskjellige videospill, og jeg skrev en E2E-test suite for å validere at en endring av den interne logikken i biblioteket ikke ville ødelegge noe uklart spill som jeg aldri hadde sett. Biblioteker fortjener alltid grundigere tester. Men for brukergrensesnitt for en enkelt applikasjon gir E2E-testing nesten aldri mening i min erfaring.