Dovrebbe essere "Arrange-Assert-Act-Assert"?

Per quanto riguarda il classico modello di prova di Arrange-Act-Assert , mi trovo spesso ad aggiungere una controasserzione che precede Act. In questo modo so che l'affermazione passeggera è davvero passiva come risultato dell'azione.

Lo considero analogo al red in red-green-refactor, dove solo se ho visto la barra rossa nel corso dei miei test so che la barra verde significa che ho scritto un codice che fa la differenza. Se scrivo un test di superamento, qualsiasi codice lo soddisferà; allo stesso modo, per quanto riguarda Arrange-Assert-Act-Assert, se la mia prima asserzione fallisce, so che qualsiasi atto avrebbe superato l'asserzione finale, quindi non stava effettivamente verificando nulla sull'Atto.

I tuoi test seguono questo schema? Perché o perché no?

Chiarimento sull'aggiornamento : l'asserzione iniziale è essenzialmente l'opposto dell'asserzione finale. Non è un'affermazione che Arrange abbia funzionato; è un'affermazione che Act non ha ancora funzionato.

Questa non è la cosa più comune da fare, ma comunque abbastanza comune da avere un proprio nome. Questa tecnica è chiamata Asserzione di guardia . È possibile trovare una descrizione dettagliata a pagina 490 nell'eccellente libro xUnit Test Patterns di Gerard Meszaros (altamente raccomandato).

Normalmente, non utilizzo questo schema da solo, poiché trovo più corretto scrivere un test specifico che convalidi qualunque precondizione sento il bisogno di garantire. Un test di questo tipo dovrebbe sempre fallire se la precondizione fallisce, e questo significa che non ne ho bisogno incorporato in tutti gli altri test. Ciò fornisce un migliore isolamento delle preoccupazioni, poiché un caso di test verifica solo una cosa.

Potrebbero esserci molte condizioni preliminari che devono essere soddisfatte per un determinato caso di test, quindi potrebbe essere necessaria più di un'asserzione di guardia. Invece di ripeterli in tutti i test, avere un (e solo uno) test per ogni precondizione mantiene il codice del test più gestibile, poiché in questo modo si avranno meno ripetizioni.

Potrebbe anche essere specificato come Arrange- Assume -Act-Assert.

C'è un handle tecnico per questo in NUnit, come nell'esempio qui: http://nunit.org/index.php?p=theory&r=2.5.7

Ecco un esempio.

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
    range.encompass(7);
    assertTrue(range.includes(7));
}

Potrebbe essere che ho scritto Range.includes()semplicemente per restituire vero. Non l'ho fatto, ma posso immaginare che avrei potuto. Oppure avrei potuto scrivere in modo sbagliato in molti altri modi. Speravo e mi aspettavo che con TDD avessi effettivamente capito bene - includes()funziona e basta - ma forse non l'ho fatto. Quindi la prima asserzione è un controllo di sanità mentale, per garantire che la seconda asserzione sia davvero significativa.

Letto da solo, assertTrue(range.includes(7));sta dicendo: "asserisci che l'intervallo modificato include 7". Leggi nel contesto della prima asserzione, sta dicendo: "asserisci che invocare encompass () fa sì che includa 7. E poiché encompass è l'unità che stiamo testando, penso che abbia un valore (piccolo).

Accetto la mia risposta; molti altri hanno frainteso la mia domanda riguardante il test del setup. Penso che questo sia leggermente diverso.

Un Arrange-Assert-Act-Asserttest può sempre essere modificato in due test:

1. Arrange-Assert

e

2. Arrange-Act-Assert

Il primo test farà valere solo ciò che è stato impostato nella fase Arrange, e il secondo test farà valere solo ciò che è accaduto nella fase Act.

Questo ha il vantaggio di fornire un feedback più preciso sul fatto che sia fallita la fase Arrange o Act, mentre nell'originale Arrange-Assert-Act-Assertquesti sono fusi e dovresti scavare più a fondo ed esaminare esattamente quale asserzione ha fallito e perché ha fallito per sapere se è stato l'Arrange or Act a fallire.

Soddisfa anche meglio l'intenzione di test di unità, poiché stai separando il tuo test in unità indipendenti più piccole.

Infine, tieni presente che ogni volta che vedi sezioni Arrange simili in test diversi, dovresti provare a estrarle in metodi di supporto condivisi, in modo che i tuoi test siano più DRY e più manutenibili in futuro.

Ora lo sto facendo. AAAA di tipo diverso

Arrange - setup
Act - what is being tested
Assemble - what is optionally needed to perform the assert
Assert - the actual assertions

Esempio di un test di aggiornamento:

Arrange: 
    New object as NewObject
    Set properties of NewObject
    Save the NewObject
    Read the object as ReadObject

Act: 
    Change the ReadObject
    Save the ReadObject

Assemble: 
    Read the object as ReadUpdated

Assert: 
    Compare ReadUpdated with ReadObject properties

Il motivo è che l'ACT non contiene la lettura del ReadUpdated è perché non fa parte dell'atto. L'atto è solo cambiare e salvare. Quindi, davvero, ARRANGE ReadUpdated for assertion, chiamo ASSEMBLE per assertion. Questo per evitare di confondere la sezione ARRANGE

ASSERT dovrebbe contenere solo asserzioni. Ciò lascia ASSEMBLE tra ACT e ASSERT che imposta l'assert.

Infine, se stai fallendo nell'Arrange, i tuoi test non sono corretti perché dovresti avere altri test per prevenire / trovare questi bug banali . Perché per lo scenario che presento, dovrebbero già esserci altri test che testano READ e CREATE. Se crei una "asserzione di guardia", potresti rompere DRY e creare manutenzione.

Lanciare un'asserzione di "controllo di integrità" per verificare lo stato prima di eseguire l'azione che si sta testando è una vecchia tecnica. Di solito li scrivo come scaffolding di test per dimostrare a me stesso che il test fa ciò che mi aspetto e li rimuovo in seguito per evitare di ingombrare i test con gli scaffolding di test. A volte, lasciare le impalcature aiuta il test a servire da narrazione.

Ho già letto di questa tecnica - forse da te tra l'altro - ma non la uso; soprattutto perché sono abituato al modulo tripla A per i miei test unitari.

Ora, mi sto incuriosendo e ho alcune domande: come scrivi il tuo test, fai fallire questa asserzione, seguendo un ciclo di refactoring rosso-verde-rosso-verde, o lo aggiungi in seguito?

A volte fallisci, forse dopo aver rifattorizzato il codice? Cosa ti dice questo? Forse potresti condividere un esempio in cui ha aiutato. Grazie.

L'ho già fatto durante le indagini su un test fallito.

Dopo un considerevole graffio alla testa, ho stabilito che la causa era che i metodi chiamati durante "Arrange" non funzionavano correttamente. Il fallimento del test è stato fuorviante. Ho aggiunto un'asserzione dopo la disposizione. Ciò ha fatto fallire il test in un punto che ha evidenziato il problema reale.

Penso che qui ci sia anche un odore di codice se la parte Arrange del test è troppo lunga e complicata.

In generale, mi piace molto "Arrange, Act, Assert" e lo uso come standard personale. L'unica cosa che non riesce a ricordarmi di fare, tuttavia, è disorganizzare ciò che ho organizzato quando le affermazioni sono state fatte. Nella maggior parte dei casi, questo non causa molto fastidio, poiché la maggior parte delle cose scompaiono automaticamente tramite la raccolta dei rifiuti, ecc. Se hai stabilito connessioni a risorse esterne, tuttavia, probabilmente vorrai chiudere quelle connessioni quando hai finito con le tue affermazioni o molti di voi hanno un server o una risorsa costosa là fuori da qualche parte aggrappandosi a connessioni o risorse vitali che dovrebbe essere in grado di cedere a qualcun altro. Questo è particolarmente importante se sei uno di quegli sviluppatori che non usa TearDown o TestFixtureTearDownpulire dopo uno o più test. Ovviamente "Arrange, Act, Assert" non è responsabile per la mia incapacità di chiudere ciò che apro; Ho solo menzionato questo "gotcha" perché non ho ancora trovato un buon sinonimo "A-word" per "dispose" da consigliare! Eventuali suggerimenti?

Dai un'occhiata alla voce di Wikipedia su Design by Contract . L'Arrange-Act-Assert Holy Trinity è un tentativo di codificare alcuni degli stessi concetti e mira a dimostrare la correttezza del programma. Dall'articolo:

The notion of a contract extends down to the method/procedure level; the
contract for each method will normally contain the following pieces of
information:

    Acceptable and unacceptable input values or types, and their meanings
    Return values or types, and their meanings
    Error and exception condition values or types that can occur, and their meanings
    Side effects
    Preconditions
    Postconditions
    Invariants
    (more rarely) Performance guarantees, e.g. for time or space used

C'è un compromesso tra la quantità di impegno speso per la configurazione e il valore che aggiunge. AAA è un utile promemoria per i passaggi minimi richiesti ma non dovrebbe scoraggiare nessuno dal creare passaggi aggiuntivi.

Dipende dal tuo ambiente / linguaggio di test, ma di solito se qualcosa nella parte Arrange fallisce, viene lanciata un'eccezione e il test non riesce a visualizzarla invece di avviare la parte Act. Quindi no, di solito non uso una seconda parte Assert.

Inoltre, nel caso in cui la tua parte Arrange sia piuttosto complessa e non generi sempre un'eccezione, potresti forse considerare di avvolgerla in un metodo e scrivere un test per essa, in modo da essere sicuro che non fallirà (senza lanciare un'eccezione).

Non uso questo schema, perché penso che fare qualcosa come:

Arrange
Assert-Not
Act
Assert

Può essere inutile, perché presumibilmente sai che la tua parte Arrange funziona correttamente, il che significa che qualsiasi cosa sia nella parte Arrange deve essere testata anche o essere abbastanza semplice da non aver bisogno di test.

Usando l'esempio della tua risposta:

public void testEncompass() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7)); // <-- Pointless and against DRY if there 
                                    // are unit tests for Range(int, int)
    range.encompass(7);
    assertTrue(range.includes(7));
}

Se vuoi davvero testare tutto nell'esempio, prova più test ... come:

public void testIncludes7() throws Exception {
    Range range = new Range(0, 5);
    assertFalse(range.includes(7));
}

public void testIncludes5() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(5));
}

public void testIncludes0() throws Exception {
    Range range = new Range(0, 5);
    assertTrue(range.includes(0));
}

public void testEncompassInc7() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(7));
}

public void testEncompassInc5() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(5));
}

public void testEncompassInc0() throws Exception {
    Range range = new Range(0, 5);
    range.encompass(7);
    assertTrue(range.includes(0));
}

Perché altrimenti mancano così tante possibilità di errore ... ad es. Dopo encompass, l'intervallo include solo 7, ecc ... Ci sono anche test per la lunghezza dell'intervallo (per assicurarsi che non comprenda anche un valore casuale), e un'altra serie di test interamente per cercare di includere 5 nell'intervallo ... cosa ci aspetteremmo: un'eccezione in encompass o l'intervallo non viene modificato?

Ad ogni modo, il punto è che se ci sono dei presupposti nell'atto che vuoi testare, metterli nella loro prova, sì?

Io uso:

1. Setup
2. Act
3. Assert 
4. Teardown

Perché una configurazione pulita è molto importante.