Ottenere l'approvazione della direzione per investire di più nei test unitari [duplicati]

IMHO, non dovresti essere in una posizione in cui devi giustificare la tua metodologia di codifica. Se sei più a tuo agio con TDD, dovresti farlo.

Per quanto ne so, non stai lavorando in una catena di montaggio in cui tutti i processi e i movimenti sono calcolati e ottimizzati. Il tuo compito ha molto spazio per le iniziative come quelle che descrivi.

In effetti, è ciò che mi aspetto dai miei dipendenti.

Ma se vuoi veramente giustificarti, S.Lott ti ha fornito due domande esistenti ( 1 2 ) nei commenti delle domande che contengono alcuni argomenti per la tua giustificazione.

Se vuoi mostrare il ROI alla gestione, non testare l'unità , a meno che tu non sospetti che determinate unità specifiche siano difettose. Al contrario, prova le funzioni , alias casi d'uso, ovvero scenari, che si verificheranno effettivamente quando il software viene utilizzato nel campo. Il ROI da questi è triplice:

1. rileva i bachi che possono essere incontrati nell'uso effettivo, evitando chiaramente problemi di manutenzione e supporto molto più costosi. [vedi sotto]

2. automatizza parte o tutta la procedura di test di accettazione, che consente di risparmiare tempo e manodopera considerevoli

3. illustra come i componenti del software dovrebbero essere utilizzati e dovrebbero interagire, il che rende molto più facile per i nuovi sviluppatori capire il sistema software, risparmiando così tempo e denaro per la formazione

Non sono un fan del testing delle unità cieche tranne che per i progetti software più esigenti. La copertura del 100% del codice può essere confortante, ma potrebbe non fornire alcun ROI significativo in senso pratico. Sono un grande fan dei test di funzionalità in stile TDD: è facile per il management comprendere l'impatto di "se l'utente immette 1000 nel campo Crisi, seleziona Travesty dal menu, quindi fa clic sul pulsante Esponenziale, otteniamo un errore di overflow di un intero nel codice di aggiornamento del database ", sarebbe per lui immaginare perché qualcuno si preoccuperebbe che" uspCrisisManagementFieldPlacementCalculator non possa gestire valori di input superiori a 999 in alcune modalità operative ". Potrebbe essere il caso in cui il modo corretto per risolvere questo particolare problema è quello di non consentire valori maggiori di 999 nel campo Crisi, a seconda esattamente di cosa dovrebbe fare l'applicazione. In altre parole, il semplice test delle unità corre il rischio di testare cose che non possono accadere e anche di generare "correzioni" che ignorano il contesto di utilizzo effettivo . Sforzarsi per la copertura del 100% del codice, come spesso è considerato un obiettivo di test unitario, può sprecare una quantità di tempo e denaro, sia testando cose che non possono realmente accadere nella pratica, sia incoraggiando correzioni e creep di scope che non considerano il contesto di utilizzo.