Facilita i dolori del test C # dell'unità quando sei l'unica persona nel test dell'unità team

Wow, questo descrive una mia situazione recente esattamente su un grande progetto esistente. Nessun test unitario e riluttanza verso / scetticismo dell'idea. Al momento della scrittura, sono stato in grado di lavorare con un'altra persona che l'ha favorita per ottenerla più accettata (sebbene io e lui siamo in gran parte gli unici a scrivere test in genere). La base del codice era (ancora) pesantemente carica di codice statico procedurale, ma sta migliorando. Ecco alcune delle cose che ho fatto per migliorare la situazione:

1. Interfaccia immediatamente tutti i singleton, specialmente quelli in uso intensivo. Quindi, inserisci l'interfaccia nelle nuove classi client che stai scrivendo per renderle testabili.
2. Scrivi wrapper per le classi statiche che implementano le interfacce e le immette in nuovi client ala (1).
3. Inizia gradualmente ad adattare le tue interfacce iniettate ai precedenti clienti di stato statico / singleton e ai test di scrittura per loro.
4. Avvio della funzionalità di estrazione dalle classi behemoth e test delle classi di responsabilità singola estratte.
5. Toccato prima, ma inserisci le tue dipendenze!
6. Scrittura o fattore per piccoli metodi e classi.
7. Continua con il refactoring fino a quando non puoi finalmente uccidere i singletons / statics.

Questi sono modi per rendere il tuo codice più testabile (e, direi, meglio in generale), ma vendere il processo ad altri è una questione diversa. Vorrei offrire il seguente consiglio per questo:

1. Scrivi test e mostra alle persone come farlo (la barriera più grande è la mancanza di conoscenza letterale su come scrivere test).
2. Se esamini il codice della gente, scrivi un test unitario per esporre un problema invece di parlarne. Mostra loro il test fallito e impegna a farlo passare.
3. Assicurati che le tue esecuzioni di test vengano eseguite rapidamente - le suite di test a lunga esecuzione marciranno e infastidiranno le persone.
4. Se l'applicazione è di grandi dimensioni, mostra agli utenti che il ciclo di feedback è molto più veloce per il refactoring modificatore di quello che è per modify-build-run-maniulate-gui-observ-refactor.
5. Unit test una funzione che si scrive e mantiene statistiche oggettive (difetti segnalati per LOC) da confrontare con codice non testato. Questa è una vittoria con la gestione.
6. Lungo le stesse linee, esegui analisi / metriche statiche sul codice testato dell'unità che, secondo la mia esperienza, tende a segnare meglio del codice non testato. Le metriche obiettive sono difficili da discutere.
7. Fai notare alle persone che proteggono il loro codice con i test unitari rende più difficile per qualcuno di venire a pasticciare con il loro codice in contrasto con le loro intenzioni originali. Sembra insignificante, ma questo è spesso un punto di forza per le persone quando se ne rendono conto.
8. Documenti di implementazione del prodotto o writeup per il consumo da parte degli stakeholder che enfatizzano la copertura del codice o il numero di test. Questo crea l'impressione (precisa) che il tuo codice sia dimostrabile e i tipi di manager / analisti / PM potrebbero iniziare a chiedere ad altri dove sono presenti le metriche di copertura / test.
9. Finalmente, e questo è quello che ho scoperto essere la maggior parte degli occhi aperti o altri sviluppatori, dimostrare la potenza dei test unitari (in particolare TDD per questo). Esegui un colpo di stato come un'importante refactoring del tuo lavoro in meno di un giorno o esegui il tuo codice perfettamente alla prima messa in funzione e avvia l'applicazione. Gli sviluppatori che lo codificano e poi trascorrono alcuni giorni nella programmazione del debugger per coincidenza saranno sobillati da questo in modo che non saranno tutti i test unitari di proselitismo nel mondo.

Prova a chiedere all'articolo di Michael Feathers Java verificabile o Testable C # o C # TUF e TUC

L'essenziale è evitare di mettere la funzione ostile al test all'interno di un costrutto ostile al test.

Non restare impigliati nel modulo utilizzato dai test di unità, perché ci sono molti modi non standard per farlo. Diamine, puoi scrivere un'app standalone che massaggia il database e cerca le incoerenze (nel caso in cui alcuni vincoli chiave siano troppo lenti). È possibile testare le cose da un metodo principale senza librerie di test unitali formali. Puoi creare un rapido script Python.

Quello che vuoi fare è cercare frutti a bassa attaccatura - ad es. cose che sono facili da testare, che probabilmente contengono bug e sono importanti.

Quando riesci, fai pubblicità al successo. Una volta che puoi dimostrare che i tuoi script e le tue cose possono catturare rapidamente molti bug, passaci al livello successivo.

Chiedi il permesso per ridimensionare il codice. Ricorda, i critici saranno ancora scettici e vorranno vedere risultati tangibili, quindi è necessario continuare a trovare bug con esso. Se devi, falla trovare bug che hai scoperto in modo manuale. Non sovraccaricare le cose solo perché ti piace il codice più pulito. Moltiplica il tuo salario orario per il numero di ore che hai speso per questo - ora devi giustificare questo investimento. Questo è il modo in cui molti altri lo vedono.

Inoltre, cerca di generare un sacco di buzz lentamente, in modo che le persone inizieranno a pensare che queste idee siano realmente loro e non tue.

Non voglio sembrare troppo pessimista qui, ma se sullo stesso progetto sei l'unico di un bel po 'di test unitari, potresti anche non farlo affatto. Compromesso nei test di integrazione, anche se sono meno precisi e più lenti.

La ragione è che ti troverai con un codice base che è solo parzialmente testato, incoerente e difficile da seguire. E questo è molto peggio nel mio libro di un progetto senza test unit . Ancora una volta, ricorda che i test di integrazione sono ancora possibili.

L'alternativa migliore sarebbe quella di convincerli che i test unitari renderanno la loro vita più facile e li aiuteranno a creare un prodotto migliore.

Se continui a scegliere (per qualche strana ragione) test unitari, quello che faccio con il codice legacy è più o meno così:

1. Inizio a sviluppare le mie classi
2. Quando ho bisogno di un servizio legacy, creo un'interfaccia per questo, quindi creo un adattatore che implementa quell'interfaccia e delega tutti i lavori al servizio legacy effettivo.

In questo modo posso lavorare con i servizi legacy e prenderli in giro nei test delle mie classi, senza modificare alcun codice legacy.

E se hai bisogno di sistemare roba nel codice legacy, trasformalo lentamente in codice testabile - iniziando dai test di integrazione e lentamente e con attenzione trasformandoli in unit test (solo della parte che sei fissaggio). Fallo e avrai lentamente sempre più parti della base di codice testabili (e testate).