Automatizzare i controlli per i test unitari "buoni"

0

C'è già una domanda su Come scrivere buoni test unitari .

In base alle risposte fornite, le proprietà chiave di un buon test unitario -

  • breve
  • Leggibile e trasmette l'intento immediatamente
  • indipendente
  • veloce
  • ripetibile
  • Verifica un singolo comportamento
  • Ha un buon nome

Tenendo conto di queste proprietà, come procedere nell'automazione dei controlli per garantire che solo i "buoni" test unitari vengano riuniti alla base di codice principale?

Sono assolutamente dell'opinione che l'automazione di questi controlli sia la strada da percorrere, se può essere ragionevolmente raggiunta. Ci sono così tante cose a cui un revisore deve fare attenzione quando accetta una richiesta di fusione: codice pulito, design, architettura, test di pulizia ecc. Quindi ridurre l'onere automatizzando i controlli che prima erano manuali è sempre il benvenuto.

    
posta thegreendroid 25.05.2017 - 02:06
fonte

3 risposte

5

Consente di ordinare le proprietà con facilità di controllo automatico:

  • Veloce: la maggior parte degli IDE ti ha già detto questo

  • Abbreviazione: il conteggio delle righe ti dice questo (a patto che non si abusi dello spazio bianco)

  • Ripetibile - Rerunning ti dice già questo

  • Independent - Questo può essere fatto elencando quali file richiede il test e cosa richiedono ...

  • Verifica una cosa (SRP) - Conta le tue affermazioni. Ce ne sono più di uno?

  • Leggibile - Semplice, scrivi un'IA che scrive il codice e invitalo alla revisione del codice. Chiedi cosa pensa.

  • Ha un buon nome - Spero che l'intelligenza artificiale sia più intelligente degli umani perché anche noi facciamo schifo.

risposta data 25.05.2017 - 02:39
fonte
7

Le tue caratteristiche dei test dell'unità mancano alcune delle funzioni importanti secondo me:

  1. Riflette e tracciabile ai requisiti
  2. Verifica tutti i requisiti per quell'unità sottoposta a test
  3. Copre tutti i casi d'angolo
  4. testa ogni riga del codice & probabilmente ogni percorso decisionale

Il punto principale di un test buono è che non riesce quando qualcosa è sbagliato e non quando nulla è sbagliato e ti consente di scoprirlo cosa c'era di sbagliato, quindi cerca:

  1. Comprehensive
  2. Accurate
  3. Completa
  4. Buoni messaggi di errore chiari con ciò che non è riuscito & come.
risposta data 25.05.2017 - 07:17
fonte
5

Come già accennato, un buon test fallisce quando il sistema in prova subisce modifiche "interrotte".

Per valutare automaticamente i nuovi test unitari in base ai criteri sopra puoi provare a implementare test delle mutazioni :

  • Determina quali parti del progetto sono coperte dal nuovo test.
  • Genera alcuni mutanti applicando (uno o più) piccole modifiche (cambiando operatori e simili) in quelle parti.
  • Esegui il nuovo test su ogni mutante. Se il test fallisce, va bene (il test potrebbe essere troppo severo, ma non è tanto un problema rispetto a un test troppo debole). Se il test non fallisce, probabilmente hai bisogno di una revisione umana delle modifiche del mutante corrispondente; potrebbe essere un'indicazione che il test è troppo debole o non copre tutti i casi.

All'inizio probabilmente otterrai molti falsi negativi. Probabilmente migliorerà selezionando accuratamente le operazioni di mutazione che in realtà portano a guasti. Ad esempio, la commutazione di dichiarazioni adiacenti di variabili locali è probabilmente improbabile che produca errori significativi.

    
risposta data 25.05.2017 - 13:05
fonte