Una cosa semplice è test coverage . Esistono anche strumenti che generano automaticamente i report, quindi puoi vedere quali linee di codice sono corrette o non coperte affatto.

Più importanti sono i "contenuti" dei test. I test includono lo "scenario del percorso felice" (dove tutto funziona come previsto), oppure si preoccupano delle eccezioni, dei casi limite ecc.? Non conosco strumenti per questo (ma non escluderò che esistano).

Controllerei anche se sono veramente interessati solo ai Test delle unità, o anche ai test di integrazione, ai test di carico, ecc. Tali test possono fornire ulteriori preziose informazioni al sistema sotto test.

In primo luogo, devi scoprire cosa intende il team con "UnitTests".

Ho scoperto che la maggior parte dei team non fa distinzioni tra

• UnitTests

e

• test automatici eseguiti con un UnitTesting Framework

unittest

I "veri" Unit Test verificano una singola aspettativa sul comportamento di un'unità in isolamento .

In questa definizione unità è

a small part of the production code with the same reason to change
(Roy Osherove, "The Art of UnitTesting")

I test unitari sono una responsabilità dello sviluppatore e vengono eseguiti al meglio seguendo l'approccio Test Driven Developement .

test automatici eseguiti con un framework UnitTesting

Puoi utilizzare qualsiasi UnitTesting Framework per creare anche altri tipi di test, in particolare test del modulo , test di accettazione , test delle prestazioni e simili .

La differenza è che testare una parte dell'applicazione ai suoi "confini naturali". In particolare, non si usano i mock creati con un quadro di simulazione come duplicati di prova per le parti che non rientrano nell'ambito del test.

Questo tipo di test è responsabilità di un tester dedicato.

a unit testing test process to improve thier output

• Dovrebbero essere richiesti test unitari
  • Ma il giudizio deve essere usato quando si decide quanto è sufficiente e quanto sono buoni i test
  • I tester delle unità iniziali devono imparare come scrivere il codice e il refactator, se necessario, che facilita il test del codice. Nota: non ho detto di iniziare i programmatori; Intendo nuovo per il test dell'unità.

• Il programmatore

  • scrive i test unitari per i codici che scrive
  • scrive i test unitari mentre il codice stesso viene scritto - TDD - sviluppo basato su test
  • Ti prometto che è più difficile scrivere test di unità dopo il fatto.

• Se tutte le revisioni del codice esaminano anche i test unitari

• I test unitari devono sempre essere eseguiti quando il codice è compilato
• I test unitari devono essere mantenuti aggiornati. Man mano che il codice cambia, anche i test dovranno necessariamente cambiare. Non consentire che i test interrotti vengano semplicemente disattivati o cancellati.
• Una o più persone devono essere evangeliste per insegnare, incoraggiare, guidare, ecc.

Questo è un processo molto basilare. C'è anche l'implementazione tecnica. Dovrai solo cercare i tuoi particolari linguaggi di sviluppo e l'ambiente.

suggest new test cases and test strategies.

Questo non ha senso nel contesto dei test unitari. Lo sviluppatore decide i casi di test per i codici che sta scrivendo. Non so cosa intendi per strategie.

• Il test delle unità deve essere guidato dai programmatori, periodo. Qualsiasi tentativo di cambiare è un esercizio inutile. Quindi il resto dei punti è più focalizzato sullo sviluppo basato su test.

• Il prodotto dovrebbe fornire un modo per testare l'aspetto della testabilità delle metriche di qualità del software per testare la funzionalità.

• Come tester, la tua strategia di test dovrebbe essere guidata dal punto di vista dei requisiti rispetto a ciò che è scritto nel codice (nel codice ci possono essere omissioni che non possono mai essere catturate dai test unitari).

• Una volta che l'apis (supponendo che le API siano fornite, che possano essere selenio) siano pubblicate, allora la suite di test dovrebbe essere creata parallelamente allo sviluppo.

• Se è presente una pipeline di integrazione continua, aggiungere l'esecuzione della suite di test come lavoro in modo che gli sviluppatori possano vedere lo stato di avanzamento del progetto.

L'efficacia può essere misurata in termini di copertura del codice / numero di test riusciti / falliti

La tua prima priorità è far funzionare gli strumenti. Scegli un framework di test che funzioni per la tua combinazione di lingua, piattaforma e IDE. Preferibilmente un framework di test che supporta report di copertura e integrazione continua (o trova un modo per integrarlo).

Sebbene sia possibile eseguire test eseguiti da strumenti personalizzati, la creazione di tale strumento non è il tuo progetto attuale. Quindi, non farlo, ottieni qualcosa che esiste già.

Chiunque sia responsabile per il codice dovrebbe scrivere e revisionare il test o delegare queste attività. Non è una buona idea avere altri test di scrittura per gli sviluppatori, altri riesaminare i test potrebbero o non funzionare.

Quali test scrivere?

Considerando che stiamo parlando di introdurre test su un progetto esistente, non inizierai con test di unità reali. Il motivo è che non siamo sicuri che il codice sia in buone condizioni per farlo. Non sappiamo ancora quanto sarà facile isolare o prendere in giro i componenti. Il codice potrebbe non disporre di interfacce o di dipendenze per facilitare il test.

Inizia scrivendo i test per i tuoi requisiti o documentazione. Cioè, se la documentazione o i requisiti dicono che quando fai X allora si verifica Y, fai un test di questo. Fai lo stesso con i contratti. Se possibile, converti questi contratti in test (non sempre possibile).

Qualsiasi difetto trovato dovrebbe tradursi in nuovi test. Se hai i mezzi per usare i test per replicare un bug, fallo. Questi saranno i tuoi test di regressione, il cui scopo è quello di fare in modo che durante le modifiche non infrangono ciò che è già stato risolto.

Una volta che hai finito con la documentazione / i requisiti, spostati per aumentare la copertura del test. L'idea è di assicurarsi che ogni strana situazione sia testata e di non utilizzare il percorso del codice di uso normale o previsto.

Una volta aggiunti i test per aumentare la copertura di un componente in un punto in cui ritieni che il modo più semplice per aumentare la copertura sia il refactoring del codice ... allora fallo. I test esistenti dovrebbero dare maggiore sicurezza durante il refactoring. Questo è quando inizi a modellare il tuo codice per facilitare il test dell'unità reale.

Tutto quanto sopra è per il codice legacy. Per il nuovo codice, scrivere test prima e durante la scrittura del codice stesso. I test dovrebbero essere una considerazione nel design del codice.