Qual è la rilevanza del test unitario in un ambiente di "Rilascio anticipato spesso"?

Negli ultimi circa un anno ho guidato il mio team verso la modalità di sviluppo release-early-release-spesso (AKA: Rapid Application Development, non Agile). Per ulteriori informazioni sul modo in cui chiudiamo la build, vedere la mia risposta qui: Un modo semplice per migliorare la qualità di rilascio in ambiente RAD

Quando abbiamo adottato RAD, le persone erano abbastanza indipendenti e stavano facendo prima i test unitari; i test integrati sono avvenuti molto più tardi nel processo. È stato un processo naturale per loro senza molta applicazione formale. Ora la situazione è abbastanza diversa:

1. L'intera piattaforma è ben integrata con build / release consolidate funzionanti sul lato client senza hot spot.

2. Nuovi requisiti di funzionalità continuano a venire e li costruiamo progressivamente mentre procediamo.

3. Le dinamiche generali del sistema sono molto importanti perché mentre gruppi di sviluppo indipendenti potrebbero seguire correttamente i processi, si sono verificati gravi guasti dovuti a circostanze complicate e non ovvie.

4. Molte parti del sistema coinvolgono nuovi algoritmi e input di ricerca, quindi le sfide (e quindi il meccanismo per i test) non sono sempre del tutto previste correttamente, come i test delle funzionalità in software ben definiti.

Di recente, stavo cercando di ottenere un quadro generale migliore per vedere se abbiamo bisogno di un miglioramento del processo. Quando mi sono seduto con la mia squadra, molti di loro hanno esitato: "Non eseguiamo più test unitari!" mentre altri hanno pensato che non dovremmo iniziare ora perché non sarà mai efficace.

I test unitari sono utili in un sistema relativamente maturo? Dovremmo almeno pesare l'ambito del test in base alla maturità delle unità? I test unitari rallenteranno il ritmo dello sviluppo? È necessario valutare i test unitari in modo diverso?

Quali sono le migliori pratiche di test per una piattaforma matura in un ambiente di rilascio-rilascio anticipato-spesso-spesso?

I test unitari non riguardano principalmente la ricerca di bug, ma assicurano che la prossima versione del sistema sia stabile come quella precedente. Più breve è il ciclo di rilascio, più diventa importante poter eseguire questi test automaticamente invece di eseguirli manualmente.

Naturalmente, se si dispone di un sistema con alcune parti indipendenti e si stava lavorando tra due versioni solo in una piccola parte del sistema, probabilmente è possibile omettere alcuni test unitari che riguardano altre parti del sistema. Ma dovresti assolutamente usare (ed estendere) i test unitari per le parti in cui stai lavorando.

Un'altra cosa è che quando un sistema cresce, ci sarà sempre più bisogno di ulteriori test di integrazione , ma ciò non significa che avrai bisogno di meno test unitari.

La vera domanda dietro la tua potrebbe essere forse diversa. È diventato più difficile scrivere test unitari da quando il tuo sistema è diventato sempre più grande? I tuoi "test unitari" sono davvero test unitari o non testano più le cose isolatamente? Ciò può essere dovuto al fatto che si basano su parti del sistema di livello inferiore che si sono stabilizzate nel tempo.

Queste cose accadono perché gli sviluppatori tendono a riutilizzare le librerie e il codice esistenti facendo direttamente riferimento a esse. Spesso ha l'effetto di rendere più difficile la scrittura di unit test, perché spesso devono fornire un ambiente più complesso e più dati di test. Se questo è il tuo problema, dovresti conoscere i concetti chiave Iniezione di dipendenza e Principio di segregazione dell'interfaccia , che potrebbero aiutarti a rendere il codice più testabile.

Si consiglia di esaminare lo sviluppo guidato dai test, in cui sono progettati i test primi e descrivere come funzionerà il nuovo codice una volta scritto. Quindi fai passare i test.

Nella mia esperienza, questo tende a rendere il codice più snello e meglio studiato, specialmente per le librerie, ed è una parte eseguibile delle specifiche (nel senso che sarà sempre una documentazione corretta).

Detto questo, i test esistenti vengono utilizzati per garantire che il codice funzioni ancora come previsto. Può rilevare la rottura del codice e consentire all'utente di garantire che il codice di terze parti funzioni come previsto durante l'aggiornamento.

Come suggerito da Doc Brown e Thorbjørn Ravn Andersen , un ambiente a rilascio anticipato spesso può trarre vantaggio ancora più dai buoni test unitari e dallo sviluppo guidato dai test rispetto a quelli con cicli di rilascio lunghi.

Se disponi di un buon sistema di integrazione continua e di test che rappresentano bene la funzionalità, hai sempre una buona idea di ciò che funziona (perché i test per quella funzionalità stanno superando) e ciò che non è ancora stato implementato ( perché non ci sono test per quella funzionalità).