Un mio collega ha avuto un'idea che ho trovato interessante.

Non sarebbe utile scrivere test durante la revisione del codice, da parte della persona che fa la revisione supponendo che non facciamo TDD?

Per questa domanda supponiamo che si tratti di un progetto puramente accademico, quindi non è in gioco la vita. Inoltre il team è composto da 4 persone. Tutti conoscono la lingua e hanno familiarità con tutti gli strumenti / librerie / framework utilizzati e possono scrivere test. Quindi fondamentalmente le persone che non sono senior fullstack guidano ingegneri ninja ma programmatori decenti.

Pro che ho trovato:

1. Incoraggia una comprensione più approfondita del codice durante la revisione per scrivere test significativi.
2. È quindi possibile aggiungere la revisione del codice di quei test eseguiti dall'autore del codice in prova.

Contro ho trovato:

1. Il ciclo di feedback tra scrittura del codice e test aumenta.

EDIT: so che non funzionerà bene su applicazioni web "normali". Quello che avevo in mente era un caso angolare in cui implementate algoritmi scientifici complessi che richiedono attenzione ai dettagli. Supponiamo che si tratti di implementare la mia libreria di grafici, la PNL, ecc. Mi chiedo se il codice che stiamo scrivendo sia isolato dai database e tale, ma molto difficile da comprendere non sarebbe il livello di controllo aggiunto, l'altra persona che deve capire la fonte codice e fare test significativi, rendere l'intero processo meno incline a quei bug meno evidenti che non bloccano l'applicazione ma alla fine rendono i tuoi risultati spazzatura?

Non sarebbe utile scrivere test durante la revisione del codice da parte della persona che sta eseguendo la revisione?

Ho scoperto che un buon momento per scrivere test è quando ti rendi conto che hai bisogno di un test per una situazione.

Il cambio di attività per i computer è costoso, e lo è ancora di più per gli esseri umani.

A questo punto, generalmente hai una buona conoscenza dei requisiti e delle dipendenze per il test. Sfrutta quindi l'immersione della tua squadra nel problema. Se hai bisogno di perfezionare il tuo nuovo test in futuro, ottimo, hai già il framework / dispositivi di test in atto e tutto ciò che devi fare è cambiare la parte che deve essere migliorata.

Se ciò accade durante la revisione del codice, perché non andare avanti e farlo? L'ho già fatto prima. Ho scoperto che è meglio che no, soprattutto se puoi farlo rapidamente, e ancora meglio se non lo avresti fatto altrimenti.

Supponendo che non facciamo TDD?

Anche se pratichi TDD, se ti rendi conto che hai bisogno di un test mentre esegui la revisione del codice, uno che non hai, perché non scrivere il test allora e lì?

Professionisti

• Sfruttate la vostra attenzione sul codice in esame.
• A volte la revisione del codice diventa un ritrovo e un momento di chat quando le persone non sono interessate. Scrivere un test incoraggia tutti a pensare più attivamente al codice in fase di revisione.
• Altri membri più giovani del team avranno l'opportunità di imparare dall'esperienza di test-writing.
• Puoi identificare talenti nella tua squadra che non sapevi di avere.

È davvero un truffatore che più test possono portare a più codice? Se il test era necessario e il codice era necessario per il test, e ora lo hai, allora è una buona cosa.

Avvertenze

Forse alcuni membri del team devono concentrarsi su altre cose. Se provoca una distrazione dalle priorità o se la revisione del codice va oltre il programma, è necessario limitare o tagliare la scrittura effettiva del test. Tuttavia, la revisione del codice può certamente identificare i test che devono essere scritti e forse possono almeno essere cancellati per essere completati dallo scrittore in seguito.

Questa è un'idea meravigliosa, con un avvertimento. Non sostituire i test scritti degli sviluppatori con i test scritti dei revisori. Chiedi ai tuoi revisori di cercare casi angolari e input che spezzeranno il codice. In altre parole, fagli provare a scrivere nuovi test che lo sviluppatore originale non pensava di scrivere.

Scrivere test di caratterizzazione è un modo assolutamente meraviglioso per comprendere un pezzo di codice che non hai scritto. Il fatto che i revisori eseguano ulteriori test nel codice consente loro di comprendere meglio come funziona il codice, come può essere infranto e come può essere migliorato. Nel frattempo, aumentando la copertura del codice.

Queste sono tutte vittorie nel mio libro.

Non penso che l'idea sia del tutto priva di merito - tuttavia, il vantaggio principale di TDD et al è che i problemi si trovano presto . Lo sviluppatore è anche nella posizione migliore per individuare quali casi angolari potrebbero richiedere un'attenzione specifica. Se questo viene lasciato fino alla revisione del codice, c'è il rischio che questa conoscenza possa andare persa.

Scrivere test durante la revisione del codice soffrirebbe dello stesso problema dei test manuali tradizionali: la comprensione delle regole aziendali può variare da sviluppatore a sviluppatore, così come la diligenza.

C'è anche la discussione secolare che verrà eseguita e se gli sviluppatori testerebbero il loro codice così bene se sapessero che c'era una funzione di test più a monte che dovrebbe catturare i bug più gravi.

Sono d'accordo con la risposta di @ RobbieDee ma ho ancora un po 'di più da aggiungere.

Se ti piace davvero questa idea, perché non fare in modo che le stesse persone scrivano i test prima del codice come criteri di accettazione eseguibili per la user story?

Ciò farebbe la stessa cosa, manterrà comunque il feedback breve e indurrà tutti a discutere della storia, che penso sia di maggior valore.

Gli aspetti negativi sono il pericolo di una riunione infinita di criteri di accettazione :-( e penso che tu stia cercando di convincere le persone nella revisione del codice a dare un'occhiata al codice di implementazione, ma suggerirei di programmare la coppia e di ruotare le coppie come una soluzione migliore per quel problema.

L'OP ha aggiunto una modifica in cui layout ulteriori dettagli di ciò che è una caratteristica difficile o pesante algoritmo.

In risposta a ciò aggiungerei che il tuo istinto di avere più occhi sul problema e sulla soluzione è buono. Forse accoppiare più persone una contro una fino a quando tutti non avranno visto il pezzo davvero difficile del codice di implementazione e dei test. Ognuno lancia nuove idee e aggiunge più valore.

C'è un'idea che a volte chiama programmazione mob, come accoppiamento ma con più persone. Questo è quasi ciò di cui stai parlando, ma aiutano al momento della stesura piuttosto che in una revisione formale in seguito. Questo non è per tutti e può richiedere un pilota forte (leader) per farlo funzionare, o un team che è molto a suo agio l'uno con l'altro e con il processo.

Fare ciò dopo la programmazione di mob suppongo che avrebbe molti degli stessi vantaggi di molti occhi che vedono il problema e suggeriscono miglioramenti e se è così che il tuo team si sente a suo agio nell'operare, questo può aiutare, ma proverei davvero a mantenere il necessario occorrenze di questo al minimo perché penso che potrebbe rallentare la squadra.

Come dici tu, se stai gestendo un team TDD, questo è discutibile poiché il codice dovrebbe già essere testato.

Nel complesso, non penso che sia un'idea così fantastica, ma dipende dal tuo approccio attuale e da ciò che funziona per te. Fondamentalmente, il problema che vedo è che perdi il vantaggio del "ciclo di feedback breve" dei test. Ricevi una notifica istantanea nel momento in cui rompi qualcosa, anche quando stai scrivendo un nuovo codice, dove i test brillano davvero. Se rinvii i test fino alla revisione del codice, in pratica stai dicendo "beh, potremmo aver risolto questo problema prima in meno tempo e con meno persone coinvolte, ma almeno tutti abbiamo imparato qualcosa (forse)". Preferirei solo assicurarmi che le persone invino il codice testato per la revisione, quindi giudichi la correttezza e la manutenibilità dei test. Dopo tutto, la revisione del codice è per la revisione, non per la scrittura del codice.

D'altra parte, ti consiglio di FIDDLE con i test / codice durante la revisione. Prova a rompere qualcosa. Commenta una condizione if. sostituire un booleano con un vero / falso letterale. Verifica se i test falliscono.

Ma sì, nel complesso, ti consiglio di scrivere i tuoi test insieme al tuo codice e di rivederli tutti in una volta.

Dipende da cosa stai facendo nella revisione del codice. Penso che ci siano due ragioni principali per scrivere test in quella fase:

• in primo luogo, se si esegue anche il refactoring durante la revisione del codice e si nota che non ci sono abbastanza unit test per coprire il tipo di refactoring che si desidera applicare, aggiungere tali test

• secondo, se il codice ti sembra come se potesse avere un bug e vuoi che lo provi (o confondi), scrivi un test per questo

Entrambi i casi esprimono la necessità di test che al momento non ci sono, ma dovrebbero esserlo. Naturalmente, potrebbe dipendere dalla cultura del tuo team se questo tipo di test dovrebbe essere scritto dal revisore o dall'autore originale, ma qualcuno dovrebbe scrivere i test.

In realtà, non penso che questo sia "un caso angolare" adatto solo per "algoritmi scientifici complessi" - al contrario, è adatto a qualsiasi tipo di software da cui ci si aspetta un certo grado di qualità.

No, non farlo. Li farai pensare che TDD sia orribile.

Penso che @ k3b abbia ragione nei commenti sulla domanda. Il codice scritto attraverso un processo in stile TDD tende a guardare e interagire in modo molto diverso dal codice scritto senza test. L'aggiunta di (buoni) test al codice non testato di solito richiede molto refactoring del codice per chiarire il suo intento e parti mobili.

Aggiungendo i test dopo aver scritto il codice, perdi gli aspetti architettonici dei vantaggi di TDD (che a mio avviso sono uno dei maggiori vantaggi). Non solo, stai chiedendo a qualcun altro, che non ha molta familiarità con il codice, di prendere il colpo di aggiungere test che sono già difficili da aggiungere.

O la persona che aggiunge i test dovrà riformattare in modo significativo il codice o dovrà lavorare molto duramente per testare il codice non verificabile. Ad ogni modo, non si godranno l'esperienza. Anche se questo potrebbe non essere il classico TDD, non lo vedranno in questo modo e potresti rimuoverlo una volta per tutte.

(Se stai già seguendo un processo TDD, scrivere test aggiuntivi durante la revisione del codice sarebbe meno dannoso, anche se nella mia esperienza, se i test sono già ben scritti, è altrettanto facile spiegare il test aggiuntivo alla persona che invia il codice per la revisione e farli scrivere.)

I test unitari durante la revisione del codice sono un cattivo sostituto per i test unitari durante lo sviluppo.

Quello che stai suggerendo ha molto senso, intuitivamente. A cosa serve la recensione? Per verificare che il codice sia buono. A cosa servono i test? Per verificare che il codice sia buono. Quindi perché non unire i due?

Ecco perché.

Portare il codice sotto test è un duro lavoro. Scrivere codice che funzioni solo all'unica cosa che deve fare è una cosa; la scrittura di codice che può essere testato in modo efficace ed efficiente è un altro. Il solo fatto che il codice ora funzioni in due scenari - "lavoro reale" e "test" - richiede una flessibilità molto maggiore, richiede che quel codice sia in grado di resistere da solo in modo significativo.

Scrivere il codice in modo che sia testabile è un lavoro e un'abilità extra. Rifattorizzare il codice di qualcun altro per la testabilità, quando non è stato scritto pensando alla testabilità all'inizio, può essere un compito importante.

Stai duplicando lo sforzo tra lo sviluppatore e il revisore. Presumibilmente, il tuo sviluppatore non sta consegnando il suo codice per la revisione senza almeno un certo livello di sicurezza che funzioni. Ha già bisogno di testare il codice. Ora, ci sono diversi livelli e ambiti di test. Il QA verifica il codice dopo lo sviluppatore e il revisore. Ma qualunque sia lo scopo che ritieni appropriato per lo sviluppatore e il revisore, non ha senso per lo sviluppatore capire come testare il codice a quel livello una volta , ma rendere i suoi test facili da riprodurre e difficili da riprodurre, quindi portare il revisore a sviluppare di nuovo il test, questa volta quelli che sono automatizzati e riproducibili. Stai solo facendo in modo che entrambi investano tempo nello scrivere gli stessi test - una volta male, una volta bene.

Stai trasformando la recensione in un passaggio molto più lungo e laborioso. Se il test è una parte importante del processo di revisione, cosa succede quando alcuni test falliscono ? Il revisore è responsabile per l'esecuzione di tutti i test, quindi deve eseguire anche il debug del codice? O verrà eseguito il ping-pong avanti e indietro, uno scrive test, l'altro li fa passare?

A volte puoi scrivere un sacco di test che sono tutti ortogonali tra loro, quindi non è necessario il ping-pong. Il revisore scrive una dozzina di test, la metà di essi fallisce, lo sviluppatore corregge i bug e tutti i test rimangono validi e ora passano. Ma ... un sacco di tempo, hai bug di blocco, o bug che richiedono riprogettazione e modifiche API, o quant'altro. Se stai assumendo la responsabilità di superare i test avanti e indietro tra revisore e sviluppatore, in realtà non sei in fase di revisione. Stai ancora sviluppando.

La necessità di scrivere test non incentiva una revisione più approfondita. Fondamentalmente significa che più approfondisci, più test devi scrivere e probabilmente saranno test difficili che devono andare in profondità nel sistema.

Confronta con lo sviluppatore che scrive i test, dove è il suo incentivo: se non scrivo test importanti, il revisore lo evidenzierà nella recensione.

Anche il revisore avrà una comprensione molto migliore del sistema se deve superare test approfonditi del codice , quindi se ha bisogno di decidere da sola quando può smettere di scrivere test di approfondimento e semplicemente OK la revisione del codice.

Se lo sviluppatore non sta scrivendo test unitari, neanche il revisore. Esistono molti ostacoli all'adozione dei test come pratica comune. Forse sei troppo sotto pressione e la tua base di codice è difficile da mettere alla prova. Forse non sei così esperto nei test e senti che non puoi permetterti la curva di apprendimento. Forse hai un assassino di ascia che invia note minacciose a persone che scrivono test. Non lo so!

Ma qualunque sia la causa, è sicuro scommettere che si applica ugualmente al revisore e allo sviluppatore. Se il team è stressato, il revisore non ha più tempo di quanto lo sviluppatore (se lo fa, ridistribuire il lavoro in modo che le persone non siano così stressate ). Se nessuno sa come scrivere bene i test unitari, probabilmente anche la recensione (se lo fa, dovrebbe sedersi e insegnare ai suoi compagni di squadra ).

Questo suggerimento sembra tentare di passare il dollaro da un collega all'altro. E non vedo alcun modo per farlo funzionare bene, prima di tutto perché è davvero difficile (e malsano) creare una situazione in cui una persona è l'unica che può fare test e un'altra persona non può farlo qualsiasi test a tutti.

Ciò che funziona è avere anche i test di copertura della recensione. Se lo sviluppatore ha già scritto dieci test, è molto più probabile che il revisore possa aiutarti a suggerirne altri dieci rispetto a quando lo sviluppatore non ne ha scritto nessuno.

E, se testare casi angolari è un compito importante, potrebbe avere senso distribuirlo in modo più ampio in tutto il team. ** Una volta che il codice è testabile in primo luogo, scrivere più test diventa molto più semplice. **

La recensione è un ottimo momento per individuare casi angolari. E, se il recensore può saltare e scrivere un test per casi angolari che trova, allora ehi - tanto meglio! Ma in generale, supponendo che il revisore possa scrivere test in cui lo sviluppatore non sembra un'idea molto scadente.