Bästa svaret
Jag arbetar för närvarande för AutoTrader, som enligt min mening gör det mycket bra.
Vi sätter dig bara ner framför en bärbar dator, med en större bildskärm och tangentbord / mus, ihopkoppling med en av våra seniorutvecklare och observeras av en annan seniorutvecklare.
Det är ganska kul för alla, utesluter de vanliga intervjunerverna och det faktum att du träffar nya människor. Men säkert, när jag är ditt par, försöker jag ha lite vänlig relation, få dig att känna dig välkommen och så vidare. Precis som jag normalt skulle göra. Jag rotar faktiskt för att du ska lyckas.
Du får en halvsides problembeskrivning av en enkel uppgift. Och sedan gör du lite parprogrammering.
Det finns flera saker som observerats och gjorts:
- Skriver du tester först? Efter kod? Aldrig?
- Använder du tester för att tänka på designen?
- Namnger du saker tydligt?
- Gillar du OOP, procedurprogrammering – eller bara en enorm funktion?
- Interagerar du bra med paret? Eller till och med alls?
- Förklarar du ditt tänkande när du går och bjuder in paret att bidra? Eller sitta i tystnad?
- Använder du standardfaciliteter i Java, som Samlingar? Om inte, vad gör du?
- Använder du IDE (som du väljer) bra?
- Delar du upp problemet bra? Dåligt? Inte alls?
Om du kan göra Java, TDD och / eller design för att bli enhetstestad och verkar vara en rimligt personlig typ, tenderar du att göra höga poäng.
Det här testet handlar inte om konstiga språkkunskaper eller konstiga algoritmkunskaper eller till och med avsluta problemet.
Det handlar om att se hur du använder de här sakerna du har skrivit på ditt CV i verkligheten.
Du kommer verkligen njuta av det. Det ger alla en rättvis bild av var en kandidat är.
Det spolar också hänsynslöst bort falska CV-påståenden.
Säg att du gör TDD? Vet du inte vad påstå betyder? Kära nån. Säg att du behärskar OOP? All kod, som inte fungerar, är i samma metod som enhetstestet vi levererade? Åh kära.
(Och ja, det hände verkligen).
För mig har det varit en ögonöppnare på båda sidor av denna process.
Svar
TDD är ett verktyg. Vad som är fel är att behandla TDD som en religion.
TDD görs vanligtvis med enhetstester: Tester av små delar eller funktioner (”enheter”) ) av din kod. Enhetstesterna ska köras snabbt , så du spottar i allmänhet alla externa serviceberoenden och ser bara till att själva koden testas.
Problemet med enorm-elefant-i-rummet med detta är att ibland innehåller de externa tjänster du har hånat det mesta av en funktions logik. Om din ”enhet” tar tag i ett objekt från en databas med en fråga och returnerar det, spottande är den interaktionen 100\% värdelös utom som ersättning för typkontroll.
Låt mig säga det igen på ett annat sätt: De så kallade ”tankeledarna ”Som predikar TDDs evangelium också predikar ofta evangeliet om dynamiska språk. Så de språk som de säger är så mycket mer produktiva kräver faktiskt en hel del mer arbete för att testa, och ofta för att skriva om dessa tester när du behöver refaktorera.
Skriv din kod på ett säkrare språk som C #, Java eller TypeScript, så gör du inte Du behöver inte oroa dig för att verifiera att typerna fortfarande är giltiga. Och det finns ton faktiska fördelar med att använda språk av statisk typ förutom att du inte behöver skriva tester som inte testar någonting.
Så vad menar jag egentligen med testerna ”att inte testa någonting”? Anta att du har en funktion som gör en SQL-fråga mot din databas. Det är tänkt att leta efter objekt som filtreras av ett visst fält. För att skriva ett snabbt enhetstest hånar du SQL-frågan. Om inte ditt hånbibliotek faktiskt kan simulera all logik som PostgreSQL arbetar med en exempeldatamängd, testas inte den verkliga kärnan logik alls ; de enda materiella testerna du kunde skriva för att verifiera logiken skulle bara bekräfta att dina hånar returnerade lämpliga svar.
Jag ser ofta hånar som bara ”verifiera att databasen kallades rätt antal gånger.” Det skulle ge dig din 100\% kodtäckning, trots allt! Bra, ett nummer för att imponera på de icke-tekniska cheferna, det betyder absolut ingenting i praktiken! Gå team Bedräglig statistik!
Nej, vad du behöver är systemtester, eller integration / E2E-tester, för att bekräfta att hela ditt system är arbetssätt. Inte bara enhetstester utan test som inte spottar samtalen till databasen utan istället utför dessa samtal.Och när en testsvit behöver ställa upp en verklig testdatabas, rensa den och såda den mellan testerna, gör TDD som en praxis opraktiskt; det är för långsamt.
Så fortsätt och skriv koden först och skriv sedan ditt E2E-test och se till att det får rätt resultat. Heck, du kan använda ögonblicksbildfunktionen för testsviter som Jesthttps: //jestjs.io/docs/en/snapshot-testing för att bara bekräfta att svaret inte ändras; titta på det en gång för att se till att det är korrekt, och sedan när du säger till Jest att det är rätt, kommer det att validera att det förblir detsamma i framtida körningar! API: er kan testas och få sina tester uppdaterade på ett nästan automatiserat sätt!
Så om du ignorerar galen från TDD-trogen kan du få ditt arbete gjort dubbelt så snabbt för att du inte behöver att vänta i 10 minuter (eller längre! Jag har sett en testsvit som tog mer än en timme …) för att hela E2E-sviten ska köras för att se att testet misslyckas innan du börjar skriva din kod.
Dessutom är att testa UI alls , som påpekas i Moray Taylors svar, är opraktiskt under många omständigheter. Det finns någon nivå av E2E-test som kan tillämpas på användargränssnittet, men för det mesta verkar avkastningen på investeringen sällan värt det för det allmänna fallet.
Som sagt, jag arbetade med ett grafikbibliotek en gång som användes av över hundra olika videospel, och jag skrev ett E2E-test svit för att det ska validera att en ändring av bibliotekets interna logik inte skulle bryta något dunkelt spel som jag aldrig ens hade sett. Bibliotek förtjänar alltid mer grundliga tester. Men för UI för en enda applikation är E2E-testning nästan aldrig meningsfullt i min erfarenhet.