Gestione dei falsi positivi in TDD o BDD

7

Sono relativamente nuovo a TDD e ho riflettuto molto su come gestire il pool di test perpetuamente in crescita che ne deriva.

Una delle mie maggiori preoccupazioni riguarda i falsi positivi.

Nella mia esperienza, non è affatto raro che una funzionalità subisca modifiche abbastanza massicce nel tempo. Per implementare una modifica, dovremmo prima scrivere un test (o molti test) per il nuovo comportamento e quindi codificare la modifica. Idealmente, tutti i test passerebbero una volta che la modifica della funzione è stata implementata correttamente.

Ma per quanto riguarda i test che hanno riguardato la prima incarnazione della funzione? Non c'è alcuna garanzia che:

  1. sono ancora pertinenti;
  2. passano ancora;
  3. il loro stato pass / fail è anche corretto.

Revisione / aggiornamento / eliminazione di questi test in un pool di test relativamente piccolo può essere gestibile, ma per quanto riguarda quando si hanno migliaia o decine di migliaia di test? Mi sembra che ci sia un grosso rischio che la tua collezione di test finisca per contenere molti falsi positivi. E, considerando che questi test sono una forma di documentazione di sistema, questo è piuttosto brutto!

Domanda: come si riduce il rischio di accumulare test falsi positivi quando si applica TDD o BDD (o qualsiasi cosa che alla fine porta ad avere una vasta collezione di test)?

    
posta MetaFight 17.12.2013 - 12:18
fonte

1 risposta

11

La chiave è che tutti i tuoi test chiaramente si riferiscano al preciso bit di funzionalità che dovrebbero testare.

Può essere attraverso nomi di test molto espressivi e una rigorosa disciplina one-assert-per-test, o una sottodirectory davvero intelligente nella tua suite di test, o riferimenti dalla suite di test al codice sorgente, o qualsiasi altra cosa. Il punto è che puoi identificare rapidamente quali test diventeranno obsoleti.

Quindi li elimini.

Sembra pazzesco, ma ogni modifica importante cancella alcune funzionalità e la sostituisce con nuove funzionalità diverse. Se utilizzi TDD, dovrai comunque scrivere nuovi test per ogni singolo bit, e fissare vecchi test invece di procedere con nuovi test e codice di produzione è solo una perdita di tempo. E questo è il motivo per cui le questioni di organizzazione, accoppiamento, coerenza ecc. Ecc. Sono altrettanto importanti nel codice di prova come nel codice di produzione!

    
risposta data 17.12.2013 - 12:23
fonte

Leggi altre domande sui tag