assertEquals, что актуально и что ожидается?

Question

Я всегда задавался вопросом, что именно означает фактическое и ожидаемое в assertEquals в таких библиотеках, как TestNG.

Если мы читаем Java Docs мы видим:

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

В моем понимании значение expected является известным один, так что мы ожидаем, что один и actual один является тот, который мы хотим проверить. Например, предположим, что мы хотим протестировать функцию fooBar, которая всегда должна возвращать 56.

В таком случае я бы сделал: assertEquals(sth.fooBar(), 56). Но с быстрым поиском на GitHub кажется, что люди делают это наоборот, поэтому assertEquals(56, sth.fooBar()). Но как ожидаемое значение может быть sth.fooBar(), когда мы даже не знаем этого значения? Похоже, что sth.fooBar() - это фактическое значение, которое мы сравниваем с ожидаемым, которое мы уже знаем.

Я знаю, что нет никакой разницы в правильности теста, но я хотел бы следовать «правильному» пути.

Answer 1

Большинство основ тестирования (семейство XUnit) основаны на рамках JUnit. Семейство функций Assert в JUnit имеет формат (expected, actual); это стало конвенцией, и большинство других рамок следовали этой конвенции.

Некоторые структуры (например, TestNG или NUnit 2.4+ для .NET) обратный порядок, что (с использованием ограничений на основе модели для NUnit) для повышения читабельности («убедитесь, что фактическое значение 56» чувствует более естественным, чем «, убедитесь, что 56 - это фактическое значение»).

Суть в следующем: придерживаться конвенции вашего каркаса. Если вы используете JUnit, сначала поставьте ожидаемое значение. Если вы используете TestNG, сначала поставьте фактическое значение. Вы правы, это не имеет никакого значения в результатах теста, когда вы случайно меняете аргументы. Но это имеет большое значение в сообщении по умолчанию, которое вы получаете от неудачного теста. Когда обратнаяassertEquals(ShouldBeTrueButReturnsFalse(), true) в JUnit не удается, сообщение по умолчанию говорит «ожидается [ложь], но нашел [истинный]», где он должен был сказать «ожидать [верно], но нашел [ложь]». Это сбивает с толку, мягко говоря, и вам не нужно иметь дело с возможным неправильным направлением этого сообщения.

Некоторые из модульных тестов в предоставляемой вами ссылке Github не соответствуют положениям конвенции и имеют одинаковую проблему. Не делай этого. Придерживайтесь условности вашего фрейма.

Answer 2

Ответ прост. JUnit имеет обратный порядок аргументов. См пример ниже:

JUnit:

void assertEquals(Object expected, Object actual)

TestNG:

void assertEquals(int actual, int expected)

Answer 3

Вы можете использовать:

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

с мавена:

<!-- 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

я тоже была такая же путаница.

Но путаница заключается в том, что поиск Github возвращает синтаксис assertEquals как для TestNG, так и для junit. Вы правильно поняли свое ожидаемое значение &.

TestNG:assertEquals(Object actual, Object expected)

JUnit:.assertEquals(Object expected, Object actual)

Например, в результате TestNG ниже кода

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

является:

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