Voglio introdurre il concetto di unit test (e test in generale) ai miei collaboratori; al momento non ci sono test e le cose vengono testate eseguendo effettivamente le attività tramite l'interfaccia utente per vedere il risultato desiderato. Come puoi immaginare, il codice è strettamente correlato all'implementazione esatta, anche con conseguente codice che dovrebbe essere in una classe e riutilizzato attraverso il sistema che viene copiato e incollato tra i metodi.
A causa dei mutati requisiti, mi è stato chiesto di modificare un modulo che ho scritto in precedenza e che è abbastanza liberamente accoppiato (non tanto quanto vorrei, ma come meglio posso ottenere senza dover introdurre molti altri concetti) . Ho deciso di includere una suite di test unitari con il mio codice revisionato per "dimostrare" che funziona come previsto e dimostrare come funziona il test; Non sto seguendo il vero TDD poiché alcuni dei codici sono già stati scritti, ma spero di seguire alcuni concetti TDD per il nuovo codice che dovrò creare.
Ora, inevitabilmente sono sicuro che mi verrà chiesto perché mi ci vorrà più di un giorno o due per scrivere il codice, dal momento che alcune parti di ciò con cui interagirò sono già presenti nel sistema (anche se senza alcun test e strettamente accoppiato), e quando controllo il codice mi verrà chiesto cosa sia questo progetto "Test". Posso spiegare le basi del test, ma non posso spiegare i benefici effettivi in un modo che gli altri avrebbero capito (perché pensano che il test richieda di eseguire l'app da solo, poiché spesso l'effettiva UI è importante per determinare se la funzionalità "funziona" " o no). Non capiscono l'idea di un accoppiamento lento (chiaramente evidente dal fatto che nulla è accoppiato liberamente, non ci sono nemmeno interfacce al di fuori del codice che ho scritto), quindi provare a usarlo come beneficio mi farebbe guadagnare molto un "Huh?" tipo di look, e di nuovo non posso essere libero come mi piacerebbe senza dover rielaborare diversi moduli esistenti e probabilmente introdurre una sorta di contenitore IoC, che sarebbe visto come una perdita di tempo e non di "programmazione".
Qualcuno ha qualche suggerimento su come posso puntare a questo codice e dire "Dovremmo iniziare a creare test unitari" senza uscire come condiscendenti (es. "Scrivere prove ti costringe a scrivere un buon codice." che probabilmente sarebbe preso significare il codice tranne il mio è cattivo ) o senza far sembrare una perdita di tempo che non aggiunge alcun valore reale?