Beste antwoord
Ik werk momenteel voor AutoTrader, die dit naar mijn mening heel goed doet.
We laten je gewoon achter een laptop zitten, met een grotere monitor en toetsenbord / muis, koppelen met een van onze senior ontwikkelaars en geobserveerd door een andere senior ontwikkelaar.
Het is best leuk voor iedereen, afgezien van de gebruikelijke interviewzenuwen en het feit dat je nieuwe mensen ontmoet. Maar zeker, als ik uw paar ben, probeer ik een beetje vriendelijk te zijn, u zich welkom te laten voelen, enzovoort. Net zoals ik normaal zou doen. Ik ben eigenlijk voor je aan het wroeten om te slagen.
Je krijgt een probleembeschrijving van een halve pagina van een eenvoudige taak. En dan doe je een beetje paarprogrammering.
Er worden verschillende dingen geobserveerd en gescoord:
- Schrijf je eerst tests? Na code? Nooit?
- Gebruik je tests om over het ontwerp na te denken?
- Noem je dingen duidelijk?
- Geef je de voorkeur aan OOP, procedureel programmeren – of slechts één enorme functie?
- Werkt u goed samen met het paar? Of zelfs helemaal niet?
- Leg je je denken uit terwijl je verder gaat en nodig je het paar uit om bij te dragen? Of zit u in stilte?
- Gebruikt u standaardfaciliteiten in Java, zoals collecties? Zo nee, wat doet u?
- Gebruikt u de IDE (die u zelf kiest) goed?
- Heeft u het probleem goed opgesplitst? Slecht? Helemaal niet?
Als je Java, TDD en / of ontwerp kunt doen om eenheid te testen, en een redelijk persoonlijke soort lijkt, heb je de neiging om hoog te scoren.
Deze test gaat niet over kennis van vreemde taalkenmerken, of vreemde kennis van algoritmen, of zelfs maar het oplossen van het probleem.
Het gaat erom te zien hoe je deze dingen die je op je cv hebt geschreven in het echt gebruikt.
Je zult er echt van genieten. Het geeft iedereen een goed beeld van waar een kandidaat zich bevindt.
Het spoelt ook meedogenloos valse cv-claims weg.
Stel dat je TDD doet? Weet u niet wat ‘beweren’ betekent? Oh jee. Stel dat je OOP onder de knie hebt? Alle code, die niet werkt, is in dezelfde methode als de unit-test die we hebben geleverd? Oh jee.
(En ja, dat is echt gebeurd).
Voor mij was het een eyeopener om aan beide kanten van dit proces te staan.
Antwoord
TDD is een hulpmiddel. Wat er mis is, is dat TDD als een religie behandelt.
TDD wordt meestal gedaan met unit-tests: tests van kleine onderdelen of functies (“units” ) van uw code. De eenheidstests worden verondersteld snel te draaien, dus u bespot in het algemeen eventuele externe serviceafhankelijkheden en zorgt ervoor dat de code zelf wordt getest.
Het enorme-olifant-in-de-kamer probleem hiermee is dat soms die externe services die je bespot de meeste logica van een functie bevatten. Als uw “eenheid” een item uit een database pakt met behulp van een zoekopdracht en het retourneert, spot die interactie 100\% nutteloos is behalve als vervanging voor typecontrole.
Laat ik dat nogmaals op een andere manier zeggen: De zogenaamde “thought leaders” “Die het evangelie van TDD prediken, prediken ook vaak het evangelie van dynamische talen. Dus de talen die ze je vertellen zijn zoveel productiever vereist eigenlijk veel meer werk om te testen, en vaak om die tests opnieuw te schrijven wanneer je moet refactoren.
Schrijf je code in een veiligere taal zoals C #, Java of TypeScript, en dat doe je niet U hoeft zich geen zorgen te maken of de typen nog steeds geldig zijn. En er zijn ton aan daadwerkelijke voordelen van het gebruik van statische typetalen, naast het feit dat u geen tests hoeft te schrijven die eigenlijk niets testen.
Dus wat bedoel ik eigenlijk met de tests “niets testen”? Stel dat u een functie heeft die een SQL-query uitvoert op uw database. Het moet items zoeken die door een bepaald veld zijn gefilterd. Om een snelle unit-test te schrijven, spot je met de SQL-query. Tenzij uw nepbibliotheek daadwerkelijk alle logica van PostgreSQL kan simuleren door aan een voorbeeldgegevensset te werken, wordt de echte logica van uw functie helemaal niet getest ; de enige inhoudelijke tests die u zou kunnen schrijven om de logica te verifiëren, zouden alleen valideren dat uw bespotten passende antwoorden retourneerden.
Ik zie vaak bespottingen dat gewoon “verifieer dat de database het juiste aantal keren is gebeld.” Dat zou u tenslotte uw 100\% codedekking opleveren! Geweldig, een nummer om indruk te maken op de niet-technische managers, dat betekent in de praktijk helemaal niets! Ga voor team misleidende statistieken!
Nee, wat u nodig heeft zijn systeemtests of integratie / E2E-tests, om te valideren dat uw hele systeem is werken. Niet alleen unit-tests, maar tests die de aanroepen naar de database niet bespotten, maar in plaats daarvan die aanroepen uitvoeren.En wanneer een testsuite een echte testdatabase moet opzetten, deze moet opschonen en tussen de tests door moet seeden, dan is TDD als praktijk onpraktisch; het is te traag.
Dus ga je gang en schrijf eerst de code, en schrijf vervolgens je E2E-test en zorg ervoor dat deze het juiste resultaat krijgt. Heck, je kunt de snapshot-functie van testsuites zoals Jesthttps: //jestjs.io/docs/en/snapshot-testing gebruiken om te valideren dat het antwoord niet verandert; bekijk het een keer om er zeker van te zijn dat het correct is, en nadat je Jest hebt verteld dat het juist is, zal het valideren dat het hetzelfde blijft in toekomstige runs! APIs kunnen op een bijna geautomatiseerde manier worden getest en hun tests laten bijwerken!
Dus als je het gerucht van de TDD-gelovigen negeert, kun je je werk twee keer zo snel doen omdat je het niet nodig hebt 10 minuten wachten (of langer! Ik heb een testsuite gezien die meer dan een uur duurde …) voordat de volledige E2E-suite werd uitgevoerd om de test te zien mislukken voordat u begint met het schrijven van uw code.
Bovendien is het testen van UI helemaal , zoals aangegeven in het antwoord van Moray Taylor, onpraktisch in veel omstandigheden. Er is enig niveau van E2E-test dat kan worden toegepast op UI, maar voor het grootste deel lijkt het rendement op investering zelden de moeite waard voor het algemene geval.
Dat gezegd hebbende, ik werkte ooit aan een grafische bibliotheek die ooit werd gebruikt door meer dan honderd verschillende videogames, en ik schreef een E2E-test suite om te valideren dat een verandering in de interne logica van de bibliotheek geen obscuur spel zou breken dat ik nog nooit had gezien. Bibliotheken verdienen altijd grondigere tests. Maar voor UI voor een enkele applicatie heeft E2E-testen bijna nooit zin in mijn ervaring.