Bedste svar
Jeg arbejder i øjeblikket for AutoTrader, der efter min mening gør det meget godt.
Vi sætter dig bare ned foran en bærbar computer med en større skærm og tastatur / mus, parret med en af vores seniorudviklere og observeret af en anden seniorudvikler.
Det er ret sjovt for alle, undtagen de sædvanlige interviewnerver og det faktum, at du møder nye mennesker. Men bestemt, når jeg er dit par, prøver jeg at have lidt venlig rapport, får dig til at føle dig velkommen og så videre. Ligesom jeg normalt ville. Jeg er faktisk rodfæstet for, at du skal få succes.
Du får en halvsides problembeskrivelse af en simpel opgave. Og så laver du lidt parprogrammering.
Der er flere ting observeret og scoret:
- Skriver du test først? Efter kode? Aldrig?
- Bruger du test til at tænke over designet?
- Navngiver du tingene tydeligt?
- Foretrækker du OOP, procedureprogrammering – eller bare en enorm funktion?
- Interagerer du godt med parret? Eller endda overhovedet?
- Forklarer du din tankegang, mens du går videre, og inviterer parret til at bidrage? Eller sidde i stilhed?
- Bruger du standardfaciliteter i Java, som f.eks. Samlinger? Hvis ikke, hvad laver du?
- Bruger du IDE (som du vælger) godt?
- Opdeler du problemet godt? Dårligt? Slet ikke?
Hvis du kan gøre Java, TDD og / eller design til at blive enhedstestet og synes at være en rimelig personlig slags, har du en tendens til at score højt.
Denne test handler ikke om underlig sprogfunktionsviden eller underlig algoritmeviden eller endda efterbehandling af problemet.
Det handler om at se, hvordan du bruger disse ting, du har skrevet på dit CV i det virkelige liv.
Du vil virkelig nyde det. Det giver alle et retfærdigt billede af, hvor en kandidat er.
Det skyder hensynsløst også falske CV-påstande ud.
Sig du gør TDD? Ved du ikke, hvad hævder betyder? Åh gud. Sig, at du har mestret OOP? Al koden, som ikke fungerer, er på samme måde som den enhedstest, vi leverede? Åh kære.
(Og ja, det skete virkelig).
For mig har det været en øjenåbner, der har været på begge sider af denne proces.
Svar
TDD er et værktøj. Hvad der er galt er at behandle TDD som en religion.
TDD udføres typisk med enhedstest: Tests af små dele eller funktioner (“enheder”) ) af din kode. Enhedstestene formodes at køre hurtigt , så du spotter generelt eventuelle eksterne serviceafhængigheder og bare sørg for, at selve koden testes.
Problemet med enorme elefanter i rummet er, at de eksterne tjenester, du har spottet, undertiden indeholder det meste af en funktions logik. Hvis din “enhed” griber et element fra en database ved hjælp af en forespørgsel og returnerer det, spottende , er interaktionen 100\% ubrugelig undtagen som erstatning for typekontrol.
Lad mig sige det igen på en anden måde: De såkaldte “tankeledere ”Der forkynder TDDs evangelium også ofte forkynder evangeliet om dynamiske sprog. Så de sprog, som de fortæller dig, er så meget mere produktive kræver faktisk meget mere arbejde for at teste, og ofte for at omskrive disse tests, når du har brug for at omformulere.
Skriv din kode på et mere sikkert sprog som C #, Java eller TypeScript, og du don behøver ikke bekymre dig om at kontrollere, at typerne stadig er gyldige. Og der er tons faktiske fordele ved at bruge sprog af statisk type ud over at du ikke behøver at skrive tests, der faktisk ikke tester noget.
Så hvad mener jeg virkelig med testene “ikke at teste noget”? Sig, at du har en funktion, der laver en SQL-forespørgsel mod din database. Det skal lede efter emner, der er filtreret efter et bestemt felt. For at skrive en hurtig enhedstest håner du SQL-forespørgslen. Medmindre dit mock-bibliotek faktisk kan simulere al logikken i PostgreSQL, der arbejder på et eksempeldatasæt, testes den virkelige kerne logik overhovedet ikke ; de eneste materielle tests, du kunne skrive for at bekræfte logikken, ville kun validere, at dine mocks returnerede passende svar.
Jeg ser ofte mocks, der blot “bekræft, at databasen blev kaldt det rigtige antal gange.” Det vil trods alt give dig din 100\% kodedækning! Fantastisk, et nummer til at imponere de ikke-tekniske ledere, der betyder absolut intet i praksis! Gå hold vildledende statistik!
Nej, hvad du har brug for er systemtest eller integration / E2E-test for at validere, at hele dit system er arbejder. Ikke kun enhedstest, men tests der ikke spotter opkaldene til databasen, men udfører i stedet disse opkald.Og når en testpakke skal oprette en faktisk testdatabase, rydde den og seede den mellem testene, gør TDD som praksis upraktisk; det er for langsomt.
Så fortsæt med at skrive koden først, og skriv derefter din E2E-test, og sørg for, at den får det rigtige resultat. Heck, du kan bruge snapshot-funktionen af testpakker som Jesthttps: //jestjs.io/docs/da/snapshot-testing for kun at validere, at svaret ikke ændres; se på det en gang for at sikre, at det er korrekt, og efter at du har fortalt Jest, at det er rigtigt, vil det validere, at det forbliver det samme i fremtidige kørsler! APIer kan testes og få deres test opdateret på en næsten automatiseret måde!
Så hvis du ignorerer TDD-trofaste, kan du få dit arbejde udført dobbelt så hurtigt, fordi du ikke har brug for at vente 10 minutter (eller længere! Jeg har set en testpakke, der tog mere end en time …) for den fulde E2E-pakke kører for at se, at testen mislykkes inden du begynder at skrive din kode.
Derudover er test UI overhovedet , som påpeget i Moray Taylor s svar, er upraktisk under mange omstændigheder. Der er noget niveau af E2E-test, der kan anvendes på brugergrænsefladen, men for det meste synes investeringsafkastet sjældent at være det værd i det generelle tilfælde.
Når det er sagt, arbejdede jeg på et grafikbibliotek en gang, der blev brugt af over hundrede forskellige videospil, og jeg skrev en E2E-test suite til at validere, at en ændring af bibliotekets interne logik ikke ville bryde noget uklart spil, som jeg aldrig engang havde set. Biblioteker fortjener altid mere grundige tests. Men for UI til en enkelt applikation giver E2E-test næsten aldrig mening i min erfaring.