Catalogo Anti-pattern di unit testing

anti-pattern : devono essere presenti almeno due elementi chiave per distinguere formalmente un effettivo anti-pattern da una semplice cattiva abitudine, cattiva pratica o cattiva idea:

• Qualche modello ripetuto di azione, processo o struttura che inizialmente sembra essere benefico, ma che alla fine produce conseguenze più negative che risultati benefici, e
• Una soluzione refactored che è chiaramente documentata, provata nella pratica e ripetibile.

Vota per l'anti-pattern TDD che hai visto "in the wild" una volta di troppo.
Il post sul blog di James Carr e la discussione correlata su yahoogroup di testdrivendevelopment

Se ne hai trovato uno "senza nome" ... pubblicalo anche tu. Un post per anti-pattern, per favore, perché i voti contino qualcosa.

Il mio interesse è quello di trovare il sottoinsieme top-n in modo che possa discuterne in un incontro al sacco nel prossimo futuro.

Cittadini di seconda classe : il codice di test non è ben rifattorizzato come il codice di produzione, contenente molto codice duplicato, rendendo difficile mantenere i test.

The Free Ride / Piggyback - James Carr, Tim Ottinger
Piuttosto che scrivere un nuovo metodo di test case per testare un'altra / caratteristica / funzionalità distinta , una nuova asserzione (e le sue azioni corrispondenti, ad esempio, Act steps from AAA) cavalca in un test case esistente .

Buon percorso

Il test rimane su percorsi felici (cioè risultati attesi) senza testare limiti ed eccezioni.

JUnit Antipatterns

L'eroe locale

Un test case che dipende da qualcosa di specifico dell'ambiente di sviluppo su cui è stato scritto per essere eseguito. Il risultato è che il test supera le scatole di sviluppo, ma fallisce quando qualcuno tenta di eseguirlo altrove.

La dipendenza nascosta

Strettamente correlato all'eroe locale, un test unitario che richiede che alcuni dati esistenti siano stati popolati da qualche parte prima che il test venga eseguito. Se quei dati non sono stati popolati, il test fallirà e lascerà poche indicazioni allo sviluppatore su cosa voleva, o perché ... costringendolo a scavare attraverso acri di codice per scoprire da dove avrebbero dovuto provenire i dati che stava usando.

Purtroppo visto fin troppe volte con le antiche .dll che dipendono da file .ini nebulosi e variegati che sono costantemente fuori sincronia su un dato sistema di produzione, per non parlare di quelli esistenti sulla tua macchina senza una consultazione approfondita con i tre sviluppatori responsabili di quelle DLL. Sospiro.

Chain Gang

Un paio di test che devono essere eseguiti in un certo ordine, cioè un test cambia lo stato globale del sistema (variabili globali, dati nel database) e il test successivo dipende da esso.

Lo vedi spesso nei test del database. Invece di eseguire un rollback teardown(), i test eseguono il commit delle modifiche nel database. Un'altra causa comune è che le modifiche allo stato globale non sono racchiuse in blocchi try / latest che vengono puliti se il test fallisce.

La
beffa A volte prendere in giro può essere utile e utile. Ma a volte gli sviluppatori possono perdere se stessi e nel loro sforzo di deridere ciò che non viene testato. In questo caso, uno unit test contiene così tanti mock, stub e / o falsi che il sistema sotto test non viene nemmeno testato, invece i dati restituiti dai mock sono ciò che viene testato.

Fonte: post di James Carr.

The Silent Catcher - Kelly?
Un test che passa se viene lanciata un'eccezione .. anche se l'eccezione che si verifica effettivamente è diversa da quella prevista dallo sviluppatore.
Vedi anche: Secret Catcher

[Test]
[ExpectedException(typeof(Exception))]
public void ItShouldThrowDivideByZeroException()
{
   // some code that throws another exception yet passes the test
}

L'ispettore
Un test unitario che viola l'incapsulamento nel tentativo di ottenere una copertura del codice del 100%, ma sa così tanto su cosa sta succedendo nell'oggetto che qualsiasi tentativo di refactoring interromperà il test esistente e richiederà che qualsiasi modifica si rifletta nell'unità test.

'come faccio a testare le mie variabili membro senza renderle pubbliche ... solo per test di unità?'

Configurazione eccessiva - James Carr
Un test che richiede una configurazione enorme per iniziare anche il test. A volte vengono utilizzate diverse centinaia di righe di codice per preparare l'ambiente per un test, con diversi oggetti coinvolti, il che può rendere difficile accertare realmente cosa viene testato a causa del "rumore" di tutte le impostazioni in corso. (Src: post di James Carr )

Sonda anale

Un test che deve usare modi folli, illegali o comunque malsani per svolgere il suo compito come: leggere campi privati ​​usando setAccessible di Java (true) o estendere una classe per accedere a campi / metodi protetti o dover mettere il test in un determinato pacchetto per accedere pacchetti / metodi globali.

Se vedi questo modello, le classi sotto test usano troppi dati nascosti.

La differenza tra questo e The Inspector è che la classe sotto test cerca di nascondere anche le cose che devi testare. Quindi il tuo obiettivo non è ottenere una copertura del test del 100%, ma essere in grado di testare qualsiasi cosa. Pensa a una classe che ha solo campi privati, un run()metodo senza argomenti e nessun getter. Non c'è modo di testarlo senza infrangere le regole.

Commento di Michael Borgwardt: Questo non è davvero un antipattern di test, è pragmatismo affrontare le carenze nel codice in fase di test. Ovviamente è meglio correggere queste carenze, ma potrebbe non essere possibile nel caso di librerie di terze parti.

Aaron Digulla: Sono d'accordo. Forse questa voce è davvero più adatta per un wiki "JUnit HOWTO" e non per un antipattern. Commenti?

Il test senza nome - Nick Pellow

Il test che viene aggiunto per riprodurre un bug specifico nel bug tracker e il cui autore ritiene non garantisca un nome proprio. Invece di migliorare un test esistente e mancante, viene creato un nuovo test chiamato testForBUG123.

Due anni dopo, quando il test fallisce, potresti dover prima provare a trovare BUG-123 nel tuo bug tracker per capire l'intento del test.

Lo Slow Poke

Uno unit test incredibilmente lento. Quando gli sviluppatori danno il via, hanno il tempo di andare in bagno, prendere una sigaretta o, peggio, dare il via al test prima di tornare a casa alla fine della giornata. (Src: post di James Carr )

ovvero i test che non verranno eseguiti con la frequenza necessaria

La farfalla

Devi testare qualcosa che contiene dati che cambiano continuamente, come una struttura che contiene la data corrente, e non c'è modo di inchiodare il risultato a un valore fisso. La parte brutta è che non ti interessa affatto questo valore. Rende solo il tuo test più complicato senza aggiungere alcun valore.

Il pipistrello della sua ala può provocare un uragano dall'altra parte del mondo. - Edward Lorenz, L'effetto farfalla

The Flickering Test (Fonte: Romilly Cocking)

Un test che solo occasionalmente fallisce, non in momenti specifici, ed è generalmente dovuto alle condizioni di gara all'interno del test. In genere si verifica durante il test di qualcosa che è asincrono, come JMS.

Forse un super set di anti-pattern " Wait and See " e " The Sleeper ".

La compilazione non è riuscita, vabbè, esegui di nuovo la compilazione. - Sviluppatore anonimo

Aspetta e vedi

Un test che esegue un codice di configurazione e quindi deve "attendere" un determinato periodo di tempo prima di poter "vedere" se il codice sottoposto a test ha funzionato come previsto. Un testMethod che utilizza Thread.sleep () o equivalente è sicuramente un test "Wait and See".

In genere, potresti vederlo se il test sta testando un codice che genera un evento esterno al sistema come un'e-mail, una richiesta http o scrive un file su disco.

Tale test può anche essere un eroe locale poiché fallirà se eseguito su una scatola più lenta o su un server CI sovraccarico.

L'anti-pattern Wait and See non deve essere confuso con The Sleeper .

Dispositivo condiviso in modo inappropriato - Tim Ottinger
Diversi casi di test nel dispositivo di prova non usano nemmeno o necessitano della configurazione / smontaggio. In parte a causa dell'inerzia dello sviluppatore nel creare un nuovo dispositivo di prova ... è più facile aggiungere un altro caso di prova alla pila

Il gigante

Uno unit test che, sebbene stia testando validamente l'oggetto in prova, può estendersi su migliaia di righe e contenere molti molti casi di test. Questo può essere un indicatore che il sistema sottoposto a test è un oggetto divino (post di James Carr).

Un segno sicuro per questo è un test che si estende su più di poche righe di codice. Spesso, il test è così complicato che inizia a contenere bug propri o di comportamento instabile.

Ci crederò quando vedrò alcune GUI lampeggianti
Una fissazione / ossessione malsana per testare l'app tramite la sua GUI `` proprio come un vero utente ''

Testare le regole aziendali tramite la GUI è una forma terribile di accoppiamento. Se scrivi migliaia di test attraverso la GUI e poi cambi la tua GUI, migliaia di test si interrompono.
Piuttosto, testare solo le cose della GUI attraverso la GUI e accoppiare la GUI a un sistema fittizio invece del sistema reale, quando si eseguono quei test. Testa le regole di business tramite un'API che non coinvolge la GUI. - Bob Martin

"Devi capire che vedere è credere, ma anche sapere che credere è vedere." - Denis Waitley

The Sleeper, aka Mount Vesuvius - Nick Pellow

Un test che è destinato a fallire in un momento e in una data specifici in futuro. Ciò è spesso causato dal controllo dei limiti errati durante il test del codice che utilizza un oggetto Data o Calendario. A volte, il test potrebbe non riuscire se eseguito in un momento della giornata molto specifico, come mezzanotte.

"The Sleeper" non deve essere confuso con l' anti-pattern " Wait And See ".

Quel codice sarà stato sostituito molto prima del 2000 - Molti sviluppatori nel 1960

L'albero morto

Un test in cui è stato creato uno stub, ma il test non è stato effettivamente scritto.

L'ho effettivamente visto nel nostro codice di produzione:

class TD_SomeClass {
  public void testAdd() {
    assertEquals(1+1, 2);
  }
}

Non so nemmeno cosa pensare al riguardo.

mi ha morso questo oggi:

Pavimento bagnato :
il test crea dati che sono persistenti da qualche parte, ma il test non viene pulito al termine. Ciò fa sì che i test (lo stesso test o forse altri test) non riescano nelle successive esecuzioni di test.

Nel nostro caso, il test ha lasciato un file in giro nella directory "temp", con i permessi dell'utente che ha eseguito il test la prima volta. Quando un utente diverso ha provato a eseguire il test sulla stessa macchina: boom. Nei commenti sul sito di James Carr, Joakim Ohlrogge si riferiva a questo come al "lavoratore sciatto", e faceva parte dell'ispirazione per "Generoso avanzi". Mi piace di più il mio nome (meno offensivo, più familiare).

The Cuckoo - Frank Carver
Un test unitario che si trova in un caso di test con molti altri e gode dello stesso processo di configurazione (potenzialmente lungo) degli altri test nel caso di test, ma poi elimina alcuni o tutti gli artefatti dal setup e crea il proprio.
Sintomo avanzato di: dispositivo condiviso in modo inappropriato

The Secret Catcher - Frank Carver
Un test che a prima vista sembra non essere testato, a causa dell'assenza di affermazioni. Ma "il diavolo è nei dettagli" .. il test si basa davvero su un'eccezione da lanciare e si aspetta che il framework di test catturi l'eccezione e la segnali all'utente come un errore.

[Test]
public void ShouldNotThrow()
{
   DoSomethingThatShouldNotThrowAnException();
}

Il vandalo ambientale

Un test "unitario" che per vari "requisiti" inizia a diffondersi nel suo ambiente, utilizzando e impostando variabili / porte di ambiente. L'esecuzione simultanea di due di questi test causerà eccezioni di "porta non disponibile", ecc.

Questi test saranno intermittenti e lasceranno gli sviluppatori a dire cose come "eseguilo di nuovo".

Una soluzione che ho visto è selezionare casualmente un numero di porta da utilizzare. Ciò riduce la possibilità di un conflitto, ma chiaramente non risolve il problema. Quindi, se puoi, prendi sempre in giro il codice in modo che non allochi effettivamente la risorsa non condivisibile.

Il test di Turing

Un testcase generato automaticamente da uno strumento costoso che ha molte, molte affermazioni raccolte dalla classe sottoposta a test utilizzando un'analisi del flusso di dati troppo intelligente per metà. Induce gli sviluppatori in un falso senso di fiducia che il loro codice sia ben testato, assolvendoli dalla responsabilità di progettare e mantenere test di alta qualità. Se la macchina può scrivere i test per te, perché non può tirare fuori il dito e scrivere l'app stessa!

Ciao stupido. - Il computer più intelligente del mondo al nuovo apprendista (da un vecchio fumetto Amiga).

Il test del palo da quaranta piedi

Temendo di avvicinarsi troppo alla classe che stanno cercando di testare, questi test agiscono a distanza, separati da innumerevoli livelli di astrazione e migliaia di righe di codice dalla logica che stanno controllando. In quanto tali, sono estremamente fragili e suscettibili a tutti i tipi di effetti collaterali che si verificano durante il viaggio epico da e verso la classe di interesse.

Sosia

Per testare qualcosa, devi copiare parti del codice sotto test in una nuova classe con lo stesso nome e pacchetto e devi usare classpath magic o un classloader personalizzato per assicurarti che sia visibile per primo (quindi la tua copia viene scelta su).

Questo modello indica una quantità malsana di dipendenze nascoste che non puoi controllare da un test.

Ho guardato la sua faccia ... la mia faccia! Era come uno specchio ma mi ha congelato il sangue.

The Mother Hen - Frank Carver
Una configurazione comune che fa molto di più del necessario per i test case. Ad esempio creando tutti i tipi di strutture di dati complesse popolate con valori apparentemente importanti e unici quando i test affermano solo la presenza o l'assenza di qualcosa.
Sintomo avanzato di: dispositivo condiviso in modo inappropriato

Non so cosa fa ... Lo aggiungo comunque, per ogni evenienza. - Sviluppatore anonimo

La prova tutto

Non posso credere che questo non sia stato menzionato fino ad ora, ma i test non dovrebbero infrangere il principio di responsabilità unica .

Mi sono imbattuto in questo così tante volte, i test che infrangono questa regola sono per definizione un incubo da mantenere.

Battitore di linea

Al primo sguardo i test coprono tutto e gli strumenti di copertura del codice lo confermano al 100%, ma in realtà i test hanno colpito solo il codice senza alcuna analisi di output.

copertura-vs-codice raggiungibile