Sono sicuro che la maggior parte di voi stia scrivendo molti test automatizzati e che durante i test unitari si sia anche imbattuto in alcune insidie comuni.
La mia domanda è: segui delle regole di condotta per scrivere i test al fine di evitare problemi in futuro? Per essere più precisi: quali sono le proprietà di buoni unit test o come scrivi i tuoi test?
I suggerimenti indipendenti dalla lingua sono incoraggiati.
Risposte:
Vorrei iniziare collegando le fonti - Pragmatic Unit Testing in Java con JUnit (c'è anche una versione con C # -Nunit .. ma ho questa .. è agnostico per la maggior parte. Consigliato.)
I buoni test dovrebbero essere UN VIAGGIO (l'acronimo non è abbastanza appiccicoso - ho una stampa del cheatsheet nel libro che ho dovuto tirare fuori per assicurarmi di aver capito bene ..)
Professionale : a lungo termine avrai tanto codice di test quanto la produzione (se non di più), quindi segui lo stesso standard di buona progettazione per il tuo codice di test. Metodi ben fattorizzati: classi con nomi che rivelano le intenzioni, nessuna duplicazione, test con buoni nomi, ecc.
Anche i buoni test vengono eseguiti velocemente . qualsiasi test che richieda più di mezzo secondo per essere eseguito .. deve essere elaborato. Più tempo impiega la suite di test per una corsa ... meno frequentemente verrà eseguita. Più modifiche lo sviluppatore tenterà di intrufolarsi tra le esecuzioni .. se qualcosa si rompe .. ci vorrà più tempo per capire quale cambiamento è stato il colpevole.
Aggiornamento 2010-08:
Oltre a questi, la maggior parte delle altre sono linee guida che riducono il lavoro a basso beneficio: ad es. "Non testare codice che non possiedi" (ad es. DLL di terze parti). Non andare a testare getter e setter. Tieni d'occhio il rapporto costi-benefici o la probabilità di difetti.
La maggior parte delle risposte qui sembra indirizzare le migliori pratiche di unit test in generale (quando, dove, perché e cosa), piuttosto che scrivere effettivamente i test stessi (come). Poiché la domanda sembrava piuttosto specifica sulla parte "come", ho pensato di postarla, presa da una presentazione "borsa marrone" che ho condotto presso la mia azienda.
1. Utilizzare nomi di metodi di test lunghi e descrittivi.
- Map_DefaultConstructorShouldCreateEmptyGisMap()
- ShouldAlwaysDelegateXMLCorrectlyToTheCustomHandlers()
- Dog_Object_Should_Eat_Homework_Object_When_Hungry()
2. Scrivi i tuoi test in uno stile Arrange / Act / Assert .
3. Fornisci sempre un messaggio di errore con le tue affermazioni.
Assert.That(x == 2 && y == 2, "An incorrect number of begin/end element
processing events was raised by the XElementSerializer");
4. Commentare il motivo del test : qual è il presupposto aziendale?
/// A layer cannot be constructed with a null gisLayer, as every function
/// in the Layer class assumes that a valid gisLayer is present.
[Test]
public void ShouldNotAllowConstructionWithANullGisLayer()
{
}
5. Ogni test deve sempre ripristinare lo stato di ogni risorsa che tocca
Tieni a mente questi obiettivi (adattato dal libro xUnit Test Patterns di Meszaros)
Alcune cose per renderlo più facile:
Non dimenticare che puoi anche eseguire test di integrazione con il tuo framework xUnit, ma tieni separati i test di integrazione e gli unit test
I test dovrebbero essere isolati. Un test non dovrebbe dipendere da un altro. Inoltre, un test non dovrebbe basarsi su sistemi esterni. In altre parole, prova il tuo codice, non il codice da cui dipende. Puoi testare queste interazioni come parte dei tuoi test di integrazione o funzionali.
Alcune proprietà di ottimi unit test:
Quando un test fallisce, dovrebbe essere immediatamente ovvio dove risiede il problema. Se devi utilizzare il debugger per rintracciare il problema, i tuoi test non sono sufficientemente granulari. Avere esattamente un'asserzione per test aiuta qui.
Quando esegui il refactoring, nessun test dovrebbe fallire.
I test dovrebbero essere eseguiti così velocemente che non esiti mai a eseguirli.
Tutti i test dovrebbero passare sempre; nessun risultato non deterministico.
I test unitari dovrebbero essere ben fattorizzati, proprio come il codice di produzione.
@Alotor: se stai suggerendo che una libreria dovrebbe avere solo unit test nella sua API esterna, non sono d'accordo. Voglio unit test per ogni classe, comprese le classi che non espongo a chiamanti esterni. (Tuttavia, se sento la necessità di scrivere test per metodi privati, allora ho bisogno di refactoring. )
EDIT: C'era un commento sulla duplicazione causata da "un'asserzione per test". In particolare, se si dispone del codice per impostare uno scenario e quindi si desidera fare più affermazioni su di esso, ma si dispone solo di un'asserzione per test, è possibile duplicare l'impostazione su più test.
Non adotto questo approccio. Invece, utilizzo dispositivi di prova per scenario . Ecco un esempio approssimativo:
[TestFixture]
public class StackTests
{
[TestFixture]
public class EmptyTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
}
[TestMethod]
[ExpectedException (typeof(Exception))]
public void PopFails()
{
_stack.Pop();
}
[TestMethod]
public void IsEmpty()
{
Assert(_stack.IsEmpty());
}
}
[TestFixture]
public class PushedOneTests
{
Stack<int> _stack;
[TestSetup]
public void TestSetup()
{
_stack = new Stack<int>();
_stack.Push(7);
}
// Tests for one item on the stack...
}
}
Quello che stai cercando è delineare i comportamenti della classe sottoposta a test.
L'intento di base è aumentare la tua fiducia nel comportamento della classe.
Ciò è particolarmente utile quando si esamina il refactoring del codice. Martin Fowler ha pubblicato un articolo interessante sui test sul suo sito web.
HTH.
Saluti,
rapinare
Il test dovrebbe inizialmente fallire. Quindi dovresti scrivere il codice che li fa passare, altrimenti corri il rischio di scrivere un test che è buggato e passa sempre.
Mi piace l'acronimo Right BICEP dal già citato libro Pragmatic Unit Testing :
Personalmente ritengo che si possa andare abbastanza lontano controllando di ottenere i risultati corretti (1 + 1 dovrebbe restituire 2 in una funzione di addizione), provando tutte le condizioni al contorno a cui si può pensare (come usare due numeri di cui la somma è maggiore del valore intero massimo nella funzione di aggiunta) e impone condizioni di errore come errori di rete.
I buoni test devono essere mantenibili.
Non ho ancora capito come farlo per ambienti complessi.
Tutti i libri di testo iniziano a scollarsi mentre la tua base di codice inizia a raggiungere le centinaia di migliaia o milioni di righe di codice.
Una buona architettura può controllare alcune delle esplosioni di interazione, ma inevitabilmente man mano che i sistemi diventano più complessi, il sistema di test automatizzato cresce con esso.
È qui che inizi a dover affrontare i compromessi:
Devi anche decidere:
dove memorizzi i casi di test nella tua base di codice?
Potrei andare avanti per sempre, ma il punto è che:
I test devono essere mantenibili.
Ho trattato questi principi qualche tempo fa in questo articolo di MSDN Magazine che ritengo sia importante da leggere per qualsiasi sviluppatore.
Il modo in cui definisco gli unit test "buoni" è se possiedono le seguenti tre proprietà:
Jay Fields ha molti buoni consigli sulla scrittura di unit test e c'è un post in cui riassume i consigli più importanti . Lì leggerai che dovresti pensare in modo critico al tuo contesto e giudicare se il consiglio vale per te. Ottieni un sacco di risposte sorprendenti qui, ma sta a te decidere quale è la migliore per il tuo contesto. Provali e fai il refactoring se ti ha un cattivo odore.
Cordiali saluti
Non dare mai per scontato che un banale metodo a 2 righe funzioni. Scrivere un rapido unit test è l'unico modo per evitare che il test nullo mancante, il segno meno fuori posto e / o un sottile errore di scoping ti mordano, inevitabilmente quando hai ancora meno tempo per affrontarlo rispetto a adesso.
Secondo la risposta "UN VIAGGIO", tranne per il fatto che i test DOVREBBERO fare affidamento l'uno sull'altro !!!
Perché?
DRY - Non ripetere te stesso - vale anche per i test! Le dipendenze del test possono aiutare a 1) risparmiare tempo di configurazione, 2) salvare le risorse del dispositivo e 3) individuare i guasti. Ovviamente, solo dato che il tuo framework di test supporta dipendenze di prima classe. Altrimenti, lo ammetto, sono cattivi.
Spesso gli unit test si basano su oggetti fittizi o dati fittizi. Mi piace scrivere tre tipi di unit test:
Il punto è evitare di riascoltare tutto per poter testare ogni funzione.
Uso una convenzione di denominazione dei test coerente descritta dagli standard di denominazione dei test unitari di Roy Osherove Ogni metodo in una determinata classe di test case ha il seguente stile di denominazione MethodUnderTest_Scenario_ExpectedResult.
Ogni sezione utilizza Upper Camel Case ed è delimitata da un punteggio inferiore.
L'ho trovato utile quando eseguo il test, i test sono raggruppati in base al nome del metodo in prova. E avere una convenzione consente ad altri sviluppatori di comprendere l'intento del test.
Aggiungo anche parametri al nome del metodo se il metodo sottoposto a test è stato sovraccaricato.