assertEquals, cosa è effettivo e cosa è previsto?

Question

Mi sono sempre chiesto quale sia esattamente il significato di reale e atteso in assertEquals in librerie come TestNG.

Se leggiamo il Docs Java vediamo:

public static void assertEquals(... actual, ... expected) 
Parameters: 
    actual - the actual value 
    expected - the expected value 

Dalla mia comprensione del valore expected è il conosciuto uno, quindi quello che ci aspettiamo, e il actual uno è quello che vogliamo verificare. Ad esempio, supponiamo di voler testare una funzione fooBar che deve sempre restituire 56.

In tal caso, farei: assertEquals(sth.fooBar(), 56). Ma con una ricerca rapida su GitHub sembra che le persone lo facciano al contrario, quindi assertEquals(56, sth.fooBar()). Ma come può il valore atteso essere sth.fooBar() quando non sappiamo nemmeno quel valore? Sembra che sth.fooBar() sia il valore reale che confrontiamo con l'aspettativa che già conosciamo.

So che non esiste alcuna differenza sulla correttezza di un test ma vorrei seguire il modo "corretto".

Answer 1

La maggior parte dei framework di test (la famiglia xUnit) si basano sul framework JUnit. La famiglia di funzioni Assert in JUnit ha il formato (expected, actual); divenne una convenzione e la maggior parte degli altri quadri seguì quella convenzione.

Alcuni quadri normativi (come TestNG o NUnit 2.4+ per NET) invertito quest'ordine (con l'uso di un modello di vincolo-based per NUnit) per aumentare la leggibilità ("assicurarsi che il valore effettivo è di 56" sente più naturale di "assicurati che 56 sia il valore attuale").

La linea di fondo è: attenersi alla convenzione del proprio framework. Se si utilizza JUnit, inserire prima il valore previsto. Se si utilizza TestNG, inserire prima il valore effettivo. Hai ragione, non fa alcuna differenza nei risultati del test quando si invertono accidentalmente gli argomenti. Ma fa una grande differenza nel messaggio predefinito che ottieni da un test in errore. Quando il vostro invertitoassertEquals(ShouldBeTrueButReturnsFalse(), true) in JUnit non riesce, il messaggio predefinito dice "previsto [false] ma ha trovato [vero]", dove avrebbe dovuto dire "previsto [vero] ma ha trovato [false]". Questo è fonte di confusione, per non dire altro, e non dovresti avere a che fare con una possibile deviazione di quel messaggio.

Alcuni dei test unitari nel collegamento Github fornito non seguono la convenzione e hanno lo stesso problema. Non farlo. Attenersi alla convenzione del proprio framework.

Answer 2

La risposta è semplice. JUnit ha un ordine inverso di argomenti. Consultare il seguente esempio:

JUnit:

void assertEquals(Object expected, Object actual)

TestNG:

void assertEquals(int actual, int expected)

Answer 3

È possibile utilizzare:

String expectedTitles[] = {"value-1", "value-2", "value-3". "value-14")}; 
List<String> expectedTitlesList = Arrays.asList(expectedTitles); 
Assert.assertTrue(expectedTitlesList.contains(("value-to-compare"))); 

con Maven:

<!-- https://mvnrepository.com/artifact/junit/junit --> 
<dependency> 
    <groupId>junit</groupId> 
    <artifactId>junit</artifactId> 
    <version>4.4</version> 
</dependency> 

<!-- https://mvnrepository.com/artifact/org.hamcrest/hamcrest-all --> 
<dependency> 
    <groupId>org.hamcrest</groupId> 
    <artifactId>hamcrest-all</artifactId> 
    <version>1.3</version> 
</dependency> 

Answer 4

Anch'io ho avuto la stessa confusione.

Ma la confusione è perché la ricerca Github restituisce la sintassi assertEquals per TestNG e junit. Hai ragione con la tua comprensione prevista &.

TestNG:assertEquals(Object actual, Object expected)

junit:.assertEquals(Object expected, Object actual)

esempio, in conseguenza TestNG inferiore codice

int x=1+2; assertEquals(x,2);

è:

java.lang.AssertionError: expected [2] but found [3] 
Expected :2 
Actual :3