Chi dovrebbe scrivere Test unitari? [duplicare]

@CarlManaster ha l'idea giusta: è responsabilità di lo sviluppatore per:

1. scrivi un test unitario,
2. verifica che non funzioni,
3. implementalo,
4. verifica che abbia esito positivo,
5. ridefinisce la funzione senza fallire il test e infine
6. refactoring il codice di test

per ogni funzione. Il motivo per ognuno di questi può essere riassunto come segue:

1. Scrivendo il test prima il codice assicura che il problema sia sufficientemente capito da fare effettivamente la cosa giusta. Puoi ancora fare una programmazione esplorativa, ma TDD significa che devi quindi eliminare il risultato e ricominciare scrivendo dei test.
2. Se il tuo test non fallisce prima di implementare la funzione, di solito stai testando la cosa sbagliata o non capisci abbastanza bene il problema.
3. L'implementazione della funzione effettiva è del tipo:)
4. Verifica che il test abbia esito positivo assicurati di avere un ciclo breve per risolverlo.
5. Il refactoring è fondamentale per assicurarsi che la complessità della tua applicazione non sfugga di mano. Se hai dei test per ogni funzione che li refactoring non dovrebbe rompere nulla.
6. Il codice di prova dovrebbe essere refactored per lo stesso motivo di cui sopra. Questo può essere complicato dal momento che è necessario assicurarsi che i test testino ancora le stesse cose di prima. Un modo per evitare di romperli è, per ogni test che si tocca (direttamente o indirettamente), per romperlo modificando ad esempio un singolo carattere nell'output previsto e eseguendolo per vedere che non riesce per il giusto motivo . Quindi basta annullare la modifica e il test dovrebbe ancora passare e fare ancora la cosa giusta.

Testare direttamente il tuo codice è una buona forma, e un sistema che incoraggia qualcuno che non sia lo sviluppatore a testarlo è un rischio, in quanto il codice potrebbe non essere nemmeno testabile senza pesanti modifiche.

Detto questo, espandere la suite di test unitari di un progetto è un ottimo modo per farti salire a bordo ora funziona.

La prima codifica del test in stile TDD funziona molto bene in una situazione in cui si dispone di una funzione specifica che è stata descritta in dettaglio che deve essere implementata, ma non aiuta a prendere decisioni architettoniche più approfondite.

I test delle unità di scrittura fanno parte del processo di progettazione, indipendentemente dal fatto che si esegua o meno il TDD. Quindi ovviamente è qualcosa che deve essere fatto dallo sviluppatore.

Test di integrazione, ora questi possono essere scritti da qualcun altro.

I test unitari, tuttavia, sono strettamente correlati all'implementazione e influenzano l'architettura.

Perché anche se non usiamo l'approccio TDD in senso stretto, dovremmo comunque progettare tenendo a mente la testabilità, quindi anche scrivere test unitari post factum ha ancora un impatto sul nostro codice.

Non è solo un metodo di apprendimento, ci fornisce preziosi feedback sulla correttezza e sulla manutenibilità del nostro codice. Inoltre, i test unitari sono una (piuttosto valida in realtà) forma di documentarlo.