Implementare test di unità presso un'azienda che non lo fa

Sembra che tu mischi due diversi tipi di test: test unitari e test di sistema / accettazione . I primi operano su un livello inferiore, testando piccoli pezzi di codice (in genere metodi individuali), che di solito risiedono in profondità all'interno del programma, non direttamente visibili agli utenti. Quest'ultima verifica l'intero programma come visto dai suoi utenti, su un livello molto più elevato di granularità. Pertanto, solo quest'ultimo può essere basato su qualsiasi forma di specifica del sistema.

Separare i due problemi rende più facile iniziare a spostarsi verso un processo di sviluppo migliore. Inizia a scrivere test delle unità il più presto possibile , indipendentemente da come il software è (non) specificato ad alto livello. Ogni volta che uno sviluppatore crea o modifica un metodo, fa qualcosa di concreto, che può (e dovrebbe) essere testato unitamente. Nella mia esperienza, anche il cambiamento dei requisiti di alto livello non influisce in modo drammatico su questi blocchi di codice di livello inferiore in modo drammatico: il codice per lo più deve essere riorganizzato, piuttosto che buttato via o riscritto completamente. Di conseguenza, la maggior parte dei test unitari esistenti continueranno a funzionare correttamente.

Una condizione importante per abilitare il test unitario è: le scadenze non dovrebbero essere decise dal management in anticipo, ma dovrebbero invece basarsi su stime di lavoro da parte degli sviluppatori (che a loro volta dovrebbero includere nella loro stima il tempo necessario per scrivere l'unità corretta test). Oppure, se la scadenza è fissa, l'ambito di consegna dovrebbe essere negoziabile. Nessuna quantità di gestione (errata) può cambiare la verità fondamentale che un determinato numero di sviluppatori può fornire solo una certa quantità di lavoro di qualità in un dato periodo di tempo.

Parallelamente a questo, inizia a discutere il modo migliore per chiarire e documentare i requisiti e trasformali in test di accettazione di alto livello. Questo è un processo più lungo di raffinamento successivo, che può richiedere anni per raggiungere uno stato migliore e stabile in tutta l'organizzazione. Una cosa sembra abbastanza certa dalla tua descrizione: cercare di correggere i requisiti in continua evoluzione scrivendo documenti di specifiche grandi in primo piano non funzionerà più . Invece, si raccomanda di adottare un approccio più agile , con frequenti rilasci di software e dimostrazioni agli utenti e molte discussioni su ciò che realmente desiderano. L'utente ha il diritto di cambiare idea sui requisiti in qualsiasi momento - tuttavia, ogni cambiamento ha il suo costo (in termini di tempo e denaro). Gli sviluppatori possono stimare il costo per ogni richiesta di modifica, che a sua volta consente al proprietario di un utente / prodotto di prendere decisioni informate. "Sicuramente, questo cambio di funzionalità sarebbe bello ... ma se ritarda il rilascio di questa altra caratteristica cruciale, e costa così tanto, mettiamola nel backlog per ora".

Chiedere agli utenti di definire casi di test di accettazione e creare dati di test è un ottimo modo per coinvolgerli di più e per creare reciproca fiducia tra utenti e sviluppatori. Ciò costringe entrambe le parti a focalizzarsi su criteri di accettazione concreti, misurabili, verificabili e a riflettere sui casi d'uso in modo molto più dettagliato che tipico. Di conseguenza, gli utenti controllano lo stato attuale dello sviluppo di prima mano con ogni versione e gli sviluppatori ottengono riscontri di valutazione più concreti e tangibili sullo stato del progetto. Nota che ciò richiede un maggiore impegno da parte degli utenti e nuove modalità operative, che possono essere difficili da accettare e imparare.

La mia esperienza con la transizione

Per molti anni ho capito male che non avevo abbastanza tempo per scrivere test unitari per il mio codice. Quando ho fatto dei test, erano cose gonfie e pesanti che mi hanno solo incoraggiato a pensare che avrei dovuto scrivere solo unit test quando sapevo che erano necessari.

Recentemente sono stato incoraggiato a utilizzare Test Driven Development e ho scoperto che si trattava di una rivelazione completa. Ora sono fermamente convinto di non avere il tempo non per scrivere test unitari.

Nella mia esperienza, sviluppando con i test in mente si finiscono con interfacce più pulite, classi più focalizzate e amp; moduli e generalmente più SOLID , codice verificabile.

Ogni volta che lavoro con un codice legacy che non ha test unitari e devo testare manualmente qualcosa, continuo a pensare "questo sarebbe molto più veloce se questo codice avesse già dei test unitari". Ogni volta che devo provare ad aggiungere funzionalità di unit test al codice con un accoppiamento elevato, continuo a pensare che "sarebbe molto più semplice se fosse stato scritto in modo disaccoppiato".

Confronto e contrasto tra le due stazioni sperimentali che supporto. Uno è stato in giro per un po 'e ha una grande quantità di codice legacy, mentre l'altro è relativamente nuovo.

Quando si aggiungono funzionalità al vecchio laboratorio, spesso si arriva al laboratorio e si impiegano molte ore a lavorare sulle implicazioni della funzionalità di cui hanno bisogno e su come posso aggiungere quella funzionalità senza influire su nessuna delle altre funzionalità. Il codice semplicemente non è impostato per consentire il test off-line, quindi praticamente tutto deve essere sviluppato on-line. Se provassi a sviluppare offline, avrei finito con più oggetti fittizi di quanto sarebbe ragionevole.

Nel laboratorio più recente, di solito posso aggiungere funzionalità sviluppandolo off-line sulla mia scrivania, prendendo in giro solo le cose che sono immediatamente necessarie, e quindi impiegando solo un breve periodo di tempo in laboratorio, stirare eventuali problemi rimanenti, non raccolto fuori linea.

Il mio consiglio

Sembra che tu abbia iniziato bene, ogni volta che farai grandi cambiamenti nel tuo flusso di lavoro di sviluppo, devi assicurarti che tutti sia coinvolto nel prendere questa decisione, e idealmente che la maggior parte persone ci hanno comprato. Dalla tua domanda, sembra che tu abbia ragione. Se la gente non ha entusiasmo per l'idea, è destinata a fallire oa generare cattiva volontà.

A meno che tu non possa presentare un caso aziendale interessante, vorrei non consigliare un'implementazione di base dei test e delle specifiche dell'unità per l'intero sistema. Come ho detto sopra, se un sistema non è progettato con test in mente, può essere molto difficile scrivere test automatici per questo.

Invece, consiglierei di iniziare in piccolo e di utilizzare la regola del boy scout :

Always leave the campground cleaner than you found it.

Se mentre stai implementando qualcosa su questo codebase, puoi identificare i test specifici richiesti per testare il comportamento esistente e la transizione dal vecchio comportamento al nuovo, quindi hai documentato entrambi la modifica delle specifiche e hai iniziato a implementare unit test per il tuo sistema.

I moduli che non tocchi non ottengono i test unitari, ma se non li stai toccando, probabilmente è perché sono già stati testati in modo approfondito e non hanno bisogno di modifiche o non vengono mai utilizzati.

Quello che vuoi evitare è sprecare un intero carico di sforzi per lo sviluppatore scrivendo test che non saranno mai necessari ( YAGNI funziona altrettanto bene per il codice di prova come per il codice di produzione * 8 '), non verrà mai più utilizzato e demoralizzerà le persone pensando che i test siano inutili dopotutto.

Sommario

Inizia in piccolo, aumenta la fiducia nei test in modo incrementale e ottieni valore commerciale dallo sviluppo di test quando e dove sono più utili per il tuo team.

La prima cosa da fare è concentrarsi non sui test, ma sull'ottenere il processo complessivo giusto. Non è necessario testare nulla se non comprendi pienamente cosa dovrebbe fare!

Quindi .. le specifiche prima e le specifiche documentate che non cambiano (beh, non immediatamente). Devi cercare di fare quelli finiti. Consiglierei un sito Web in cui gli utenti possono caricare le specifiche o digitarle direttamente. Puoi anche collegarlo a un bug tracker e una guida sui progressi del progetto.

È probabile che sia tutto ciò di cui hai veramente bisogno. È possibile aggiungere test di unità a quello interno e la gestione non deve mai sapere che gli sviluppatori stanno facendo test unitari. In un certo senso, è così che dovrebbe essere.

Avrai ancora bisogno di fare test del sistema, ma anche quello può essere collegato al sito web di gestione del progetto, una volta rilasciato, il team di test (anche se è un altro fortunato sviluppatore a rotazione) può aggiornarlo con i test che hanno usato per vedere se l'intera cosa è appesa insieme.

Onestamente non penso che cambierà da un giorno all'altro, se sei abituato a ottenere le specifiche del passaparola, allora la battaglia cambierà quasi completamente questo comportamento - e otterrai resistenza a questo. Un utente (o BA o PM o chiunque) che è abituato a dire "fai solo x" e ora ha bisogno di scrivere tutto non risponderà bene, è probabile che scriveranno documenti specifici e poi chiarirli con gli aggiornamenti del passaparola. Quindi dimentica i test delle unità e inizia il grosso problema che hai con il ciclo di vita dello sviluppo.

Primo problema: per "dare agli sviluppatori una serie di dati di test e test unitari", è necessario scrivere quei test unitari, che sono un compito degli sviluppatori. I test unitari non sostituiscono nemmeno le specifiche: la specifica è pensata per avere un livello di astrazione più alto rispetto ai test unitari.

Secondo problema: sembra che si desideri la copertura massima del test unitario. In questo caso, sì, costerà troppo tempo e denaro per scrivere sia test che codice in un contesto in cui i requisiti cambiano costantemente. Decidi invece quali parti del codice sono critiche e testare solo quelle parti. In molti casi, i requisiti che cambiano non influenzano le parti critiche del prodotto. Un cliente (o amministratore delegato, o qualsiasi cosa) di solito chiede di spostare questo pannello a destra, o di cambiare il colore di questo titolo da rosso a verde: cose a cui nessuno importa e che non richiede un test intensivo. D'altra parte, un cliente non chiederà mai di cambiare l'algoritmo di hash da SHA512 a SHA256 o di cambiare il modo in cui si memorizzano le sessioni, mentre sono quelle parti che richiedono il maggior numero di test.