Qual è la rilevanza del test unitario in un ambiente di "Rilascio anticipato a rilascio frequente"?

Question

Qual è la rilevanza del test unitario in un ambiente di "Rilascio anticipato a rilascio frequente"?

#1 da (15 voti)
#2 da (4 voti)
#3 da (3 voti)

10

Negli ultimi un anno circa, ho guidato il mio team verso la modalità di sviluppo a rilascio anticipato-spesso-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 nell'ambiente RAD

Quando abbiamo adottato RAD, le persone erano abbastanza indipendenti e stavano facendo prima il test delle unità; i test integrati si sono verificati molto più tardi nel processo. Era un processo naturale per loro senza molta applicazione formale. Ora la situazione è abbastanza diversa:

L'intera piattaforma è ben integrata con build / release consolidati che lavorano sul lato client senza punti caldi.
I nuovi requisiti di funzionalità continuano a venire e noi li costruiamo in modo incrementale man mano che procediamo.
Le dinamiche complessive del sistema sono molto importanti perché, mentre i gruppi di sviluppo indipendenti potrebbero seguire correttamente i processi, sono sorti gravi fallimenti a causa di circostanze complicate e non ovvie.
Molte parti del sistema coinvolgono nuovi algoritmi e input di ricerca, quindi le sfide (e quindi il meccanismo per i test) non sono sempre previste correttamente, come test delle funzionalità in software ben definiti.

Recentemente, stavo cercando di ottenere un quadro generale migliore per vedere se abbiamo bisogno di miglioramenti del processo. Quando mi sono seduto con la mia squadra, molti di loro hanno esitato: "Non facciamo più test unitari!" mentre altri pensavano 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 delle unità in modo diverso?

Quali sono le migliori pratiche di testing per una piattaforma matura in un ambiente release-early-release-spesso?

unit-testing rad

posta Dipan Mehta 13.01.2012 - 11:50

fonte

3 risposte

Leggi altre domande sui tag unit-testing rad

La sessione web è "Bad Design"? Perché? Ogni classe che scrivo aderisce ad un'interfaccia?

score 15 · Answer 1

I test unitari non servono principalmente a trovare bug in primo luogo - servono a garantire che la prossima versione del sistema sia stabile come la versione precedente. Più breve è il ciclo di rilascio, più diventa importante eseguire questi test automaticamente anziché eseguirli manualmente.

Naturalmente, se hai un sistema con alcune parti indipendenti e lavori tra due rilasci solo in una piccola parte del sistema, probabilmente puoi omettere alcuni test unitari che riguardano altre parti del sistema. Ma dovresti assolutamente usare (ed estendere) i test unitari per le parti su 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 un minor numero di test unitari.

La vera domanda dietro la tua potrebbe essere diversa. È diventato più difficile scrivere test unitari da quando il tuo sistema è diventato sempre più grande? I tuoi test di "unità" sono in realtà test di unità o non testano più le cose in isolamento? Ciò può essere dovuto al fatto che si affidano a 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 riferimento direttamente a loro. Spesso ha l'effetto che i test delle unità di scrittura diventano più difficili, 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 Interfaccia principio di segregazione , che può aiutarti a rendere il codice più verificabile da unità.

score 4 · Answer 2

Dovresti considerare di esaminare lo sviluppo basato su test, in cui i test sono progettati prima e descrivono 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 biblioteche, ed è una parte eseguibile delle specifiche (il che significa che sarà sempre una documentazione corretta).

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

score 3 · Answer 3

Come suggerito da Doc Brown e Thorbjørn Ravn Andersen , un ambiente Rilascio anticipato spesso può beneficiare ancora di più da un buon test delle unità e sviluppo guidato dai test rispetto a uno con cicli di rilascio lunghi.

Se hai un buon sistema Integrazione continua e test che rappresentano bene la funzionalità, hai una buona idea in qualsiasi momento cosa funziona (perché i test per quella funzionalità stanno passando) e cosa non è ancora stato implementato (perché non ci sono test per quella funzionalità).