I test di alcuni progetti dovrebbero essere scritti dalla persona reale che esegue la codifica (di solito senior nel nostro team) o può essere eseguita da programmatori junior con meno esperienza?
Non esiste una risposta unica a questa domanda. Ovviamente, se sei un'azienda con un singolo sviluppatore, lo sviluppatore dovrebbe scrivere i test. Se sei un'organizzazione di mille sviluppatori, la risposta sarà diversa.
Assumendo un team "normale" con pochi sviluppatori e forse alcune persone dedicate ai test, va qualcosa del genere:
Nel modello di mischia, non c'è distinzione tra "sviluppatore" e "QA". Il team nel suo complesso è responsabile della qualità del software e il team decide caso per caso chi dovrebbe eseguire il test.
Molte persone intelligenti pensano che gli sviluppatori dovrebbero scrivere tutti i loro test. Ho lavorato in organizzazioni del genere e abbiamo sempre consegnato un software di eccezionale qualità. In quelle aziende, non solo i test di scrittura dovrebbero senior devs, devono devono .
Altre persone molto intelligenti credono che gli sviluppatori dovrebbero non testare il proprio codice perché hanno i paraocchi. "Non ho bisogno di testare X, le mie modifiche non possono averlo influenzato". Per combattere devi sempre avere qualcun altro a scrivere i test. Ho lavorato in questi tipi di organizzazioni e anche lì abbiamo fornito un codice di alta qualità.
La linea di fondo è che se sei uno sviluppatore, tu sei in definitiva responsabile della qualità del codice che produci. Ciò significa che dovresti scrivere dei test, indipendentemente dalla struttura organizzativa, e se hai altri membri del team, dovresti lavorare con loro per assicurarti che il codice sia stato testato correttamente.
In termini pratici, le uniche persone che possono rispondere a questa domanda per te sono te stesso e il tuo team. È perfettamente ragionevole per i programmatori di livello superiore scrivere test (e se sono dei buoni programmatori, non dovrai mai chiedere loro di farlo perché è solo una parte del lavoro). È anche perfettamente ragionevole per i giovani scrivere test: questo è un buon modo per loro di imparare il software.
In entrambi i casi, non c'è dovrebbe . Dovresti fare tutto ciò che consente al tuo team di creare software con un livello di qualità appropriato.
Modifica: ho letto il titolo come test unitario:
Ho già sentito questa idea, e IMHO penso che sia una pessima idea forzare i test unitari solo sugli sviluppatori junior.
Creerai una divisione inutile nella tua squadra.
Gli sviluppatori dovrebbero scrivere test unitari per il proprio codice. Sia il codice che i test di unità verranno in futuro aggiornati da altri sviluppatori, in quanto le modifiche alle funzionalità e i bug vengono scoperti in base alla disponibilità delle risorse.
Non fidarsi dei giovani con caratteristiche reali non è il modo migliore per gestire i progetti. Iniziali su funzioni più piccole o più facili, lasciali testare da un'unità e possono aprirsi a funzioni più grandi e più difficili.
Idealmente, nella progettazione basata su test, il test viene scritto prima che venga scritta una singola riga di codice. Qualcuno scrive il test fallito, qualcuno scrive il codice (che passa).
In questo modello, non importa troppo chi scrive il test (o chi fa il codice). Ciò che è richiesto è che il test descriva accuratamente la funzionalità da scrivere prima di scrivere il codice. Se questa comprensione dei requisiti richiede un programmatore esperto, allora è quello che lo scrive.
Tuttavia, una volta scritto il test, se è stato scritto bene, chiunque dovrebbe essere in grado di scrivere il codice per esso che supera il test. Se non altro, questo indica che i senior dovrebbero scrivere tutti i test e quindi delegare la codifica del budello del codice ad altre persone che possono farlo.
Dopo il test dell'unità di fatto è .. meno che ideale. Sfortunatamente, quando questo accade, spesso viene lasciato ai juniores per "ottenere la copertura richiesta". Tali sforzi sono spesso difficili perché sono noiosi e non testano completamente il codice in questione (lasciando i bug che diventano capro espiatorio sulla persona che ha scritto il test per non averlo preso).
È fantastico che i programmatori junior acquisiscano esperienza con la base di codice. Costringendoli a scrivere dopo che il test dell'unità di fatto non è il modo per farlo.