Comments 13
assertThat("expected").isEqualTo(actual);
Потому что предполагаемая концепция использования. С точки зрения прошёл/не прошёл тест разницы нет, но при разборе почему не прошёл, сильно помогают сообщения, формируемые асертами. А вот в них уже будет
org.opentest4j.AssertionFailedError:
expected: "actual"
but was: "expected"Что при более сложных проверках может вводить в заблуждение.
Концепция большинства тестов достаточно простая: вызвал метод, получил результат, проверил результат.
В assertThat() можно передать только один параметр - результат, который будем проверять. Это достаточно интуитивно. Я пока что не встречал разработчиков, у которых с этим бы возникли проблемы.
assertEquals() из JUnit противоречит концепции "чистого кода" - два параметра одинакового типа, которые легко перепутать местами, и код скомпилируется. В большинстве случаев это не проблема, но иногда мешает: читать логи упавшего теста в CI-пайплайне (особенно когда локально тест проходит) или на code review, когда один разработчик поучает другого правильно использовать assertEquals.
Потому что цепочка будет проверять ожидаемое значение, а не актуальное.
Представьте assertThat(123).isNotNull().isEqualTo(var);
Нет, спасибо, нам достаточно TestNG, мы не голодные.
Не цепляйтесь за устаревающие проекты. Hamcrest не радует нас новыми версиями с октября 2019. Просто замените его более современным решением:
Но почему это проблема, что он не обновлялся (если конечно там нет критических багов)? Это какой-то js подход получается, где обязательно нужно самый новый фреймворк, а все, что старше полугода, ужасное легаси?
И забавно тоже, что пример с Hamcrest совпадает практически слово в слово с AssertJ.
Я бы порекомендовал добавлять описание ошибки. Вот у нас я автомачу мобильные тесты один, а юзают их все манульщики. И писать 2 <> 3 не совсем ясно, что такое 2 и почему 3. Ошибки должен понимать человек кто видит продукт первый раз.
И еще я не вижу мягкие ассерты, которые не останавливают тест. Это очень удобно когда тест флоу бежит до конца и накапливает сбор мелких ошибок.
Так много категоричных утверждений) А что вам это дало? Много народу уволилось, когда самодур начальник стал заставлять их делать всё только его любимой и единственно правильной библиотекой и никак иначе?
Вы знаете, никто не уволился) Опробовано в двух разных организациях на двух разных командах. Адекватные люди не спешат навешивать на других ярлыки и, тем более, увольняться из-за нового инструмента, который внедряется.
Сопротивление новому - черта, свойственная любому человеку. AssertJ - капля в море. Внедрение checkstyle, например, вызывает гораздо большее сопротивление, но даже оно преодолимо без потерь.
Я правильно понимаю, что вы мне карму минусанули и неадекватным назвали, из-за того что, я усомнился в сверзполезности и категоричности перехода с junit4 на junit5?) Какие критерии полезности перехода?
AssertJ как способ значительно улучшить код ваших тестов