assertEquals, co jest rzeczywiste i czego się oczekuje?

Question

Zawsze zastanawiałem się, co dokładnie oznacza rzeczywiste i oczekiwane w assertEquals w bibliotekach takich jak TestNG.

Jeśli czytamy Java Dokumenty widzimy:

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

Z mojego zrozumienia wartość expected znany jest jeden, więc jeden oczekujemy, a jeden actual jest jeden chcemy zweryfikować. Załóżmy na przykład, że chcemy przetestować funkcję fooBar, która zawsze musi zwrócić 56.

W takim przypadku zrobiłbym: assertEquals(sth.fooBar(), 56). Ale szybkie wyszukiwanie na GitHub wydaje się, że ludzie robią to na odwrót, więc. Ale jak można oczekiwać wartości sth.fooBar(), gdy nawet nie znamy tej wartości? Wydaje się, że sth.fooBar() jest rzeczywistą wartością, którą porównujemy z oczekiwaną, którą już znamy.

Wiem, że nie ma różnicy w poprawności testu, ale chciałbym podążać "poprawną" drogą.

Answer 1

Większość ram testowania (rodzina xUnit) oparte są na ramach JUnit. Rodzina funkcji Assert w JUnit ma format (expected, actual); stało się konwencją, a większość innych ram podążała za tą konwencją.

Niektóre ramy (jak TestNG lub NUnit 2.4+ NET) odwrócone że zamówienie (z wykorzystaniem modelu opartego na więzów NUnit) w celu zwiększenia czytelności („upewnić się, że rzeczywista wartość jest 56” czuje bardziej naturalny niż "upewnij się, że 56 jest rzeczywistą wartością").

Najważniejsze to: trzymać się konwencji ramowej. Jeśli używasz JUnit, najpierw wpisz oczekiwaną wartość. Jeśli używasz TestNG, najpierw wprowadź wartość rzeczywistą. Masz rację, to nie ma znaczenia w wynikach testu, gdy przypadkowo odwrócisz argumenty. Ale robi dużą różnicę w domyślnym komunikacie, który dostajesz z testu na awarię. Gdy odwróconeassertEquals(ShouldBeTrueButReturnsFalse(), true) w JUnit zawiedzie, komunikat domyślny mówi "oczekiwano [false], ale okazało [true]", gdzie powinien powiedzieć "oczekiwano [true], ale okazało [false]". Jest to mylące, i nie powinieneś mieć do czynienia z możliwym błędnym przekazaniem tej wiadomości.

Niektóre z testów jednostkowych w udostępnianym przez Ciebie połączeniu Github nie są zgodne z konwencją i mają ten sam problem. Nie rób tego. Trzymaj się konwencji ramowej.

Answer 2

Odpowiedź jest prosta. JUnit ma odwrotną kolejność argumentów. Patrz przykład poniżej:

JUnit:

void assertEquals(Object expected, Object actual)

TestNG:

void assertEquals(int actual, int expected)

Answer 3

Można użyć:

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

z 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

Ja też miał ten sam błąd.

Ale zamieszanie jest spowodowane tym, że wyszukiwanie Githuba zwraca składnię assertEquals dla obu wersji TestNG i junit. Masz poprawne oczekiwane rzeczywiste zrozumienie &.

TestNG:assertEquals(Object actual, Object expected)

JUnit.assertEquals(Object expected, Object actual)

przykład w wyniku TestNG poniżej kodu

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

jest: