Migliore risposta
Attualmente sto lavorando per AutoTrader, che lo fa molto bene, a mio parere.
Ti sediamo davanti a un laptop, con un monitor e una tastiera / mouse più grandi, mentre ci associamo a uno dei nostri sviluppatori senior e ci osserviamo da un altro sviluppatore senior.
È abbastanza divertente per tutti, tranne i soliti nervi da intervista e il fatto che stai incontrando nuove persone. Ma certamente, quando sono la tua coppia, cerco di avere un rapporto amichevole, di farti sentire il benvenuto e così via. Proprio come farei normalmente. In realtà sto facendo il tifo per il tuo successo.
Ottieni una descrizione del problema di mezza pagina di un compito semplice. E poi fai un po di programmazione in coppia.
Ci sono diverse cose osservate e valutate:
- Scrivi prima i test? Dopo il codice? Mai?
- Usi i test per pensare al design?
- Dai nomi chiaramente alle cose?
- Preferisci lOOP, la programmazione procedurale o solo una funzione enorme?
- Interagisci bene con la coppia? O addirittura del tutto?
- Spieghi il tuo pensiero mentre procedi e inviti la coppia a contribuire? O stai seduto in silenzio?
- Usi servizi standard in Java, come le collezioni? Se no, cosa fai?
- Usi bene lIDE (che è di tua scelta)?
- Suddividi bene il problema? Male? Niente affatto?
Se riesci a testare Java, TDD e / o design e sembri un tipo ragionevolmente personalizzabile, tendi a ottenere un punteggio elevato.
Questo test non riguarda la conoscenza delle funzionalità di un linguaggio strano, o la conoscenza di algoritmi strani, o anche la risoluzione del problema.
Si tratta di vedere come usi queste cose che hai scritto nel tuo CV nella vita reale.
Ti piacerà davvero. Dà a tutti un quadro chiaro di dove si trova un candidato.
Elimina spietatamente anche affermazioni false sui CV.
Dici che fai TDD? Non sai cosa significa “affermare”? Oh caro. Dici di aver imparato lOOP? Tutto il codice, che non funziona, è nello stesso metodo dello unit test che abbiamo fornito? Oh mio Dio.
(E sì, è successo davvero).
Per me, è stato aprire gli occhi su entrambi i lati di questo processo.
Risposta
TDD è uno strumento. Ciò che non va è trattare TDD come una religione.
TDD viene in genere eseguito con unit test: test di piccole parti o funzioni (“unità” ) del tuo codice. Gli unit test dovrebbero essere eseguiti velocemente , quindi in genere si simula qualsiasi dipendenza da servizi esterni e ci si assicura solo che il codice stesso venga testato.
Il problema enorme-elefante nella stanza è che a volte quei servizi esterni che hai deriso contengono la maggior parte della logica di una funzione. Se la tua “unità” prende un elemento da un database utilizzando una query e lo restituisce, deride che linterazione è al 100\% inutile tranne che come sostituto del controllo del tipo.
Lasciatemelo dire di nuovo in un modo diverso: I cosiddetti “leader di pensiero “Che predicano il vangelo di TDD spesso predicano anche il vangelo dei linguaggi dinamici. Quindi le lingue che ti stanno dicendo sono molto più produttive in realtà richiedono molto più lavoro per i test e spesso per riscrivere quei test quando è necessario eseguire il refactoring.
Scrivi il tuo codice in un linguaggio più sicuro come C #, Java o TypeScript e non Non devi preoccuparti di verificare che i tipi siano ancora validi. E ci sono tonnellate di vantaggi effettivi derivanti dallutilizzo di linguaggi di tipo statico oltre a non dover scrivere test che in realtà non testano nulla.
Allora cosa intendo veramente con i test “non testare nulla”? Supponi di avere una funzione che esegue una query SQL sul tuo database. Dovrebbe cercare elementi filtrati da un campo particolare. Per scrivere uno unit test veloce, deridi la query SQL. A meno che la tua falsa libreria possa effettivamente simulare tutta la logica di PostgreSQL lavorando su un set di dati di esempio, la logica di base della tua funzione non viene affatto testata ; gli unici test sostanziali che potresti scrivere per verificare la logica avrebbero solo convalidato che i tuoi mock restituivano risposte appropriate.
Vedo spesso derisioni che semplicemente “verifica che il database sia stato chiamato il giusto numero di volte”. Dopotutto, questo ti darebbe la copertura del codice al 100\%! Fantastico, un numero per impressionare i manager non tecnici che in pratica non significa assolutamente nulla! Vai a fare squadra Statistiche ingannevoli!
No, ciò di cui hai bisogno sono test di sistema o test di integrazione / E2E, per confermare che lintero sistema è Lavorando. Non solo unit test, ma verifica che non derida le chiamate al database, ma invece le esegue.E quando una suite di test ha bisogno di creare un database di test effettivo, cancellandolo e seminandolo tra i test, ciò rende il TDD come pratica impraticabile; è troppo lento.
Quindi vai avanti e scrivi prima il codice, quindi scrivi il tuo test E2E e assicurati che ottenga il risultato corretto. Diamine, puoi utilizzare la funzione snapshot di suite di test come Jesthttps: //jestjs.io/docs/en/snapshot-testing per convalidare semplicemente che la risposta non cambia; guardalo una volta per assicurarti che sia corretto, quindi dopo aver detto a Jest che è corretto, confermerà che rimarrà lo stesso nelle esecuzioni future! Le API possono essere testate e aggiornare i loro test in modo quasi automatico!
Quindi, se ignori i deliri dei fedeli TDD, puoi completare il tuo lavoro due volte più velocemente perché non ti serve di aspettare 10 minuti (o più! Ho visto una suite di test che ha impiegato più di unora …) per lesecuzione della suite E2E completa per vedere il fallito prima di iniziare a scrivere il codice.
Inoltre, testare linterfaccia utente affatto , come sottolineato nella risposta di Moray Taylor, è poco pratico in molte circostanze. Esiste un certo livello di test E2E che può essere applicato allinterfaccia utente, ma per la maggior parte il ritorno sullinvestimento raramente sembra valere la pena per il caso generale.
Detto questo, una volta stavo lavorando a una libreria grafica che veniva utilizzata da oltre un centinaio di videogiochi diversi e ho scritto un test E2E suite per convalidare che una modifica alla logica interna della libreria non romperebbe un gioco oscuro che non avevo mai visto. Le biblioteche meritano sempre test più approfonditi. Ma per linterfaccia utente per una singola applicazione, i test E2E non hanno quasi mai senso nella mia esperienza.