Implementazione di unit test presso un'azienda che non lo fa

Il capo dello sviluppo software della mia azienda ha appena "rassegnato le dimissioni" (ovvero licenziato) e ora stiamo cercando di migliorare le pratiche di sviluppo della nostra azienda. Vogliamo implementare test unitari in tutto il software creato da qui in poi.

Il feedback degli sviluppatori è questo:

• Sappiamo che i test sono preziosi
• Ma, stai sempre cambiando le specifiche, quindi sarebbe una perdita di tempo
• E le tue scadenze sono così strette che non abbiamo abbastanza tempo per testare comunque

Il feedback del CEO è questo:

• Vorrei che la nostra azienda avesse dei test automatici, ma non so come farlo
• Non abbiamo tempo di scrivere grandi documenti di specifica

In che modo gli sviluppatori ottengono le specifiche ora? Passaparola o slide PowerPoint. Ovviamente, questo è un grosso problema. Il mio suggerimento è questo:

• Diamo anche agli sviluppatori una serie di dati di test e unit test
• Questa è la specifica. Spetta al management essere chiaro e quantitativo su ciò che vuole.
• Gli sviluppatori possono metterlo qualunque altra funzionalità ritenga necessaria e non deve essere coperta da test

Bene, se sei mai stato in un'azienda che si trovava in questa situazione, come hai risolto il problema? Questo approccio sembra ragionevole?

Sembra che tu stia mescolando due diversi tipi di test: test unitari e test di sistema / accettazione . I primi operano a 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'ultimo verifica l'intero programma visto dai suoi utenti, con un livello di granularità molto più elevato. Pertanto, solo quest'ultimo può essere basato su qualsiasi forma di specifica del sistema.

Separare le due questioni semplifica l'avvio di un processo di sviluppo migliorato. Inizia a scrivere unit test 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 in unità. In base alla mia esperienza, anche la modifica di requisiti di alto livello non influisce in modo significativo su questi blocchi di codice di livello inferiore in modo significativo: il codice deve principalmente essere riorganizzato, piuttosto che gettato via o riscritto completamente. Di conseguenza, la maggior parte dei test unitari esistenti continuerà a funzionare correttamente.

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

Parallelamente a questo, inizia a discutere il modo migliore per chiarire e documentare i requisiti e trasformarli in test di accettazione di alto livello. Questo è un processo più lungo di raffinamento successivo, che può facilmente richiedere anni per arrivare a uno stato migliore e stabile in un'intera organizzazione. Una cosa sembra abbastanza sicura dalla tua descrizione: cercare di risolvere i requisiti in costante cambiamento scrivendo in anticipo documenti di specifica di grandi dimensioni non funzionerà . Invece, si consiglia di spostarsi verso un approccio più agile, con frequenti versioni di software e dimostrazioni per gli utenti e molte discussioni su ciò che realmente desiderano. L'utente ha il diritto di cambiare idea sui requisiti in qualsiasi momento, tuttavia ogni modifica 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 all'utente / al proprietario del prodotto di prendere decisioni informate. "Sicuramente, questo cambio di funzionalità sarebbe bello ... ma se ritarda il rilascio di quest'altra caratteristica cruciale, e costa così tanto, mettiamolo nel backlog per ora".

Indurre gli utenti a definire casi di test di accettazione e creare dati di test è un ottimo modo per coinvolgerli maggiormente e creare fiducia reciproca tra utenti e sviluppatori. Ciò costringe entrambe le parti a concentrarsi su criteri di accettazione concreti, misurabili e verificabili e a pensare ai casi d'uso in modo molto più dettagliato del tipico. Di conseguenza, gli utenti possono verificare personalmente lo stato attuale dello sviluppo con ogni versione e gli sviluppatori ottengono un feedback di misurazione più concreto e tangibile sullo stato del progetto. Si noti tuttavia che ciò richiede un maggiore impegno da parte degli utenti e nuove modalità operative, che possono essere difficili da accettare e da imparare.

La mia esperienza con la transizione

Per molti anni ho avuto il malinteso di non avere abbastanza tempo per scrivere test unitari per il mio codice. Quando scrivevo i test, erano cose gonfie e pesanti che mi incoraggiavano solo a pensare che avrei dovuto scrivere test unitari solo quando sapevo che erano necessari.

Di recente sono stato incoraggiato a utilizzare Test Driven Development e l'ho trovato una rivelazione completa. Ora sono fermamente convinto di non avere il tempo di non scrivere unit test .

Nella mia esperienza, sviluppando pensando ai test, si ottengono interfacce più pulite, classi e moduli più mirati e in genere più codice SOLID , testabile.

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 elevato accoppiamento, continuo a pensare "sarebbe molto più facile se fosse stato scritto in modo disaccoppiato".

Confronto e contrasto delle due stazioni sperimentali che io sostengo. Uno è in circolazione da un po 'e ha una grande quantità di codice legacy, mentre l'altro è relativamente nuovo.

Quando si aggiunge funzionalità al vecchio laboratorio, spesso si tratta di scendere in laboratorio e passare 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 i test off-line, quindi praticamente tutto deve essere sviluppato on-line. Se provassi a sviluppare off-line, finirei con più oggetti finti di quanto sarebbe ragionevole.

Nel laboratorio più recente, di solito posso aggiungere funzionalità sviluppandola off-line sulla mia scrivania, prendendo in giro solo le cose che sono immediatamente necessarie e quindi trascorrendo solo un breve periodo in laboratorio, risolvendo eventuali problemi rimanenti non risolti -linea.

Il mio consiglio

Sembra che tu abbia iniziato bene, ogni volta che farai grandi cambiamenti al tuo flusso di lavoro di sviluppo, devi assicurarti che tutti siano coinvolti nel prendere quella decisione, e idealmente che la maggior parte delle persone ci abbia accettato. Dalla tua domanda, sembra che tu abbia capito bene. Se le persone non hanno l'entusiasmo per l'idea, è condannato a fallire o generare cattiva volontà.

A meno che non sia possibile presentare un caso aziendale convincente, non consiglierei un'implementazione approfondita di test unitari e specifiche per l'intero sistema. Come accennato in precedenza, se un sistema non è progettato pensando ai test, può essere molto difficile scrivere test automatici per questo.

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

Lascia sempre il campeggio più pulito di quello che hai trovato.

Se mentre stai implementando qualcosa su questa base di codice, puoi identificare i test specifici richiesti per testare il comportamento esistente e passare dal vecchio comportamento al nuovo, allora hai entrambi documentato la modifica delle specifiche e hai iniziato a implementare i test delle unità per il tuo sistema.

I moduli che non tocchi non ottengono i test unitari, ma se non li tocchi, probabilmente è perché sono già stati accuratamente testati in uso e non necessitano di modifiche o non vengono mai utilizzati.

Quello che vuoi evitare è sprecare un sacco di sforzi degli sviluppatori per scrivere test che non saranno mai necessari ( YAGNI funziona altrettanto bene per il codice di test come per il codice di produzione * 8 '), non verrà mai più usato e demoralizzerà le persone in pensando che i test siano inutili dopo tutto.

Sommario

Inizia in piccolo, costruisci la fiducia nei test in modo incrementale e guadagna valore dallo sviluppo dei test quando e dove avvantaggiano maggiormente il tuo team.

La prima cosa da fare è concentrarsi non sui test, ma sull'ottenere il processo complessivo corretto. Inutile provare qualcosa se non capisci perfettamente cosa dovrebbe fare!

Quindi .. prima le specifiche e le specifiche documentate che non cambiano (bene, non immediatamente). Devi guardare a fare quelli. 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 sull'avanzamento del progetto.

Le probabilità sono, questo è tutto ciò di cui hai veramente bisogno. È possibile aggiungere test unitari a quelli interni e la direzione non deve mai sapere che gli sviluppatori stanno eseguendo test unitari. In un certo senso, è così che dovrebbe essere.

Sarà comunque necessario eseguire i test di sistema, ma anche quello può essere collegato al sito Web di gestione del progetto, una volta rilasciato, il team di test (anche se quello è un altro fortunato sviluppatore in rotazione) può aggiornarlo con i test che hanno usato per vedere se il tutto si blocca insieme.

Onestamente non penso che questo cambierà da un giorno all'altro, se sei abituato a ottenere specifiche sul passaparola, allora la battaglia cambierà quasi del tutto questo comportamento e otterrai resistenza. Un utente (o BA o PM o chiunque) che è abituato a dire "basta farlo fare x" e ora ha bisogno di scrivere tutto non risponderà bene, è probabile che scriveranno vaghi documenti di specifica e poi li chiariranno con aggiornamenti passaparola. Quindi dimentica i test unitari e inizia il grosso problema che hai con il ciclo di vita dello sviluppo.

Primo problema: per "fornire agli sviluppatori una serie di dati di test e test unitari", devi prima scrivere quei test unitari, che è un compito degli sviluppatori. Neanche i test unitari sostituiscono le specifiche: si intende che il livello di astrazione sia superiore ai test unitari.

Secondo problema: sembra che tu voglia la massima copertura del test unitario. In questo caso, sì, costerà troppo tempo e denaro per scrivere sia i test che il codice in un contesto in cui i requisiti cambiano costantemente. Decidi invece quali parti del codice sono critiche e l'unità verifica solo quelle parti. In molti casi, i requisiti che cambiano non incidono sulle parti critiche del prodotto. Un cliente (o CEO, o qualsiasi altra cosa) di solito chiede di spostare questo pannello a destra o di cambiare il colore di questo titolo da rosso a verde: cose che non interessano a nessuno e che non richiedono test intensivi. 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 memorizzi le sessioni, mentre sono quelle parti che richiederanno il maggior numero di test.