Legjobb válasz
Jelenleg az AutoTradernél dolgozom, aki véleményem szerint ezt nagyon jól csinálja.
Csak leülünk egy laptop elé, nagyobb monitorral, billentyűzettel / egérrel, párosítva az egyik vezető fejlesztőnkkel, és egy másik vezető fejlesztő figyelte.
Nagyon szórakoztató Mindenki, eltekintve a szokásos interjúidegektől és attól, hogy új emberekkel találkozik. De minden bizonnyal, amikor a párod vagyok, megpróbálok egy kicsit barátságos kapcsolatot kialakítani, éreztetni fogod magad és így tovább. Pontosan úgy, ahogy én szoktam. Tulajdonképpen a siker érdekében szurkolok.
Féloldalas probléma leírást kap egy egyszerű feladatról. És akkor csinál egy kis páros programozást.
Számos dolgot figyeltek meg és szereztek:
- Először teszteket írsz? Kód után? Soha?
- Tesztekkel gondolkodik a tervezésen?
- Világosan nevezi meg a dolgokat?
- Előnyben részesíti az OOP-t, az eljárási programozást – vagy csak egyet óriási funkció?
- Jól kommunikálsz a párral? Vagy akár egyáltalán?
- Megmagyarázza a gondolkodását, miközben halad, és felkéri a párost, hogy járuljon hozzá? Vagy csendben ül?
- Használ szokásos szolgáltatásokat a Java-ban, például a Gyűjteményeket? Ha nem, akkor mit csinál?
- Jól használja az IDE-t (amely az Ön választása)?
- Jól felosztotta a problémát? Rosszul? Egyáltalán nem?
Ha meg tudja csinálni a Java-t, a TDD-t és / vagy a tervezést az egység teszteléséhez, és ésszerű személyiségnek tűnik, akkor általában magas pontszámot ér el.
Ez a teszt nem furcsa nyelvtudásról, vagy furcsa algoritmus-ismeretről szól, vagy akár a probléma befejezéséről szól.
Arról van szó, hogy megnézzük, hogyan használják a CV-ben írt dolgokat a való életben.
Nagyon élvezni fogja. Mindenki számára tisztességes képet ad arról, hogy hol van egy jelölt.
Kíméletlenül kiöblíti a hamis önéletrajzi igényeket is.
Mondja, hogy TDD-t csinál? Nem tudja, mit jelent az „állítás”? Ó, drágám. Mondja, hogy elsajátította az OOP-t? Az összes kód, amely nem működik, ugyanazon a módszeren van, mint az általunk megadott egység teszt? Ó, kedves.
(És igen, ez valóban megtörtént).
Számomra ez a folyamat mindkét oldalán szemet nyitott.
Válasz
A TDD egy eszköz. A baj az, hogy a TDD-t vallásként kezeli.
A TDD-t általában egységtesztekkel végzik: Kis alkatrészek vagy funkciók („egységek”) tesztjei ) kódját. Az egységteszteknek állítólag gyorsan kell futniuk , ezért általában kigúnyolják az esetleges külső szolgáltatásfüggőségeket, és csak a kód tesztelését biztosítják.
A hatalmas elefánt a szobában ezzel az a probléma, hogy néha azok a külső szolgáltatások, amelyeket kigúnyoltál, tartalmazzák a függvény logikájának nagy részét. Ha az „egysége” lekérdezéssel elkap egy elemet az adatbázisból, és visszaadja, gúnyolva az interakció 100\% -ban haszontalan kivéve a típusellenőrzés helyettesítőjeként.
Hadd mondjam el, hogy megint másképp: Az úgynevezett „gondolatvezetők” ”Akik a TDD evangéliumát hirdetik, gyakran a dinamikus nyelvek evangéliumát is hirdetik. Tehát azok a nyelvek, amelyeket neked mondanak, sokkal eredményesebbek valójában sokkal több munkát igényel a teszteléshez, és gyakran újra kell írni ezeket a teszteket, amikor refrakterre van szükség.
Írja be a kódját egy olyan biztonságosabb nyelvre, mint a C #, a Java vagy a TypeScript, és nem kell nem kell aggódnom a típusok érvényességének ellenőrzése miatt. A statikus típusú nyelvek használatából pedig tonna tényleges előny származik, amellett, hogy nem kell olyan teszteket írni, amelyek valójában semmit sem tesztelnek.
Tehát mit értek valójában a „semmit nem tesztelő” teszteken? Tegyük fel, hogy van olyan funkciója, amely SQL lekérdezést készít az adatbázisával szemben. Állítólag egy adott mező által szűrt elemeket kell keresnie. Gyors egységteszt megírásához csúfolja az SQL lekérdezést. Hacsak az álmodell-könyvtár nem képes ténylegesen szimulálni a PostgreSQL logikáját, amely egy mintaadatkészleten dolgozik, a funkció valódi magja logikája egyáltalán nincs tesztelve ; az egyetlen érdemi teszt, amelyet a logika ellenőrzésére írhatna, csak azt igazolná, hogy gúnyai megfelelő válaszokat adtak vissza.
Gyakran látok olyan gúnyokat, amelyek egyszerűen „ellenőrizze, hogy az adatbázist megfelelő számú alkalommal hívták-e meg”. Végül is ezzel megszereznéd a 100\% -os kód lefedettséget! Nagyszerű, a nem technikai vezetőket lenyűgöző szám, amely a gyakorlatban semmit sem jelent! Menj a csapat megtévesztő statisztikáihoz!
Nem, amire szükséged van, akkor rendszer tesztekre, vagy integrációs / E2E tesztekre van szükséged annak igazolására, hogy a teljes rendszered dolgozó. Nem csak egységtesztek, hanem olyan tesztek is, amelyek nem nem csúfolják az adatbázis hívásait, hanem végrehajtják ezeket a hívásokat.És amikor egy tesztcsomagnak ki kell állnia egy tényleges tesztadatbázist, ki kell törölnie és be kell vetnie a tesztek közé, az a TDD-t mint gyakorlatot kivitelezhetetlenné teszi; túl lassú.
Tehát folytassa, először írja be a kódot, majd írja meg az E2E tesztet, és győződjön meg róla, hogy a megfelelő eredményt kapja. A fene, használhatja az olyan tesztkészletek pillanatkép funkcióját, mint a Jesthttps: //jestjs.io/docs/en/snapshot-testing, és csak annak ellenőrzésére szolgál, hogy a válasz nem változik-e; nézze meg egyszer, hogy megbizonyosodjon arról, hogy helytálló-e, majd miután elmondta Jestnek, hogy igaza van, igazolja, hogy a jövőben is ugyanaz marad! Az API-kat majdnem automatizált módon tesztelhetjük, és frissíthetjük tesztjeiket!
Tehát ha figyelmen kívül hagyja a TDD híveinek tombolását, kétszer olyan gyorsan végezheti el munkáját, mert nincs szüksége rá várni 10 percet (vagy tovább! Láttam egy tesztcsomagot, amely több mint egy órát vett igénybe …) a teljes E2E csomag futtatásához, hogy a teszt sikertelen legyen , mielőtt elkezdené írni a kódot.
Ezenkívül az UI tesztelése egyáltalán , amint arra Moray Taylor válasza rámutatott, sok körülmények között nem praktikus. van egy bizonyos szintű E2E teszt, amely alkalmazható a kezelőfelületre, de a beruházások megtérülése többnyire általában nem tűnik érdemesnek.
Ennek ellenére egy grafikus könyvtáron dolgoztam, amelyet több mint száz különféle videojáték használt, és írtam egy E2E tesztet programcsomagot annak ellenőrzéséhez, hogy a könyvtár belső logikájának megváltoztatása nem törhet-e meg valami homályos játékot, amelyet még soha nem is láttam. A könyvtárak mindig megérdemelnek alaposabb vizsgálatokat. De egyetlen alkalmazás felhasználói felületénél az E2E tesztelésnek szinte soha nincs értelme tapasztalataim szerint.