Всем привет!
Надеюсь все уже перешли на JUnit 5?
У JUnit 5 много крутых фич по сравнению с 4-й версией, например:
1) более удобная работа с параметризованными тестами через @ParametrizedTest, который вешается на метод - можно миксовать параметризированные и непараметризированные тесты в одном тестовом классе
2) возможность параметризировать не только входные параметры, но и все остальное в тесте с помощью динамически генерируемых тестов DynamicTests https://www.baeldung.com/junit5-dynamic-tests
3) есть возможность проверки исключений и таймаута через методы - assertThrows и assertTimeout. Это более правильно - assert идет после Act (я про Arrange-Act-Assert) и позволяет делать несколько проверок в одном тестовом методе
4) условное выполнение тестов в зависимости от среды: @EnabledOnOs, @EnabledOnJre, @EnabledIfSystemProperty, @EnabledIfEnvironmentVariable, также можно создавать свои условия
5) @RepeatedTest для повтора теста N раз
6) @DisplayName - полезно для задания говорящего имени теста для параметризированных тестов, к примеру
7) @Nested для складывания тестовых классов в "матрешку". Полезно, если у часть тестов нужно выполнить отнаследовавшись от базового класса
8) assertAll - объединение нескольких assert-ов в тесте. Полезно, как способ отключить fail fast режим проверок в JUnit - прогнать все assert-ы в тесте несмотря на падение одного из них.
9) ну и наконец механизм extensions. В 4-й версии был механизм Runner-ов, но его ограничение состояло в том, что на класс можно было повесить один Runner. А extensions может быть сколько угодно. Вот пример реализации BDD с помощью extension https://www.infoq.com/articles/deep-dive-junit5-extensions/ Здесь же есть пример 3-го способа параметризации теста - через ParameterResolver.
10) кроме всего прочего механизм extension добавляет store - контекст для обмена данными между тестами. Важно: для модульных тестов это антипаттерн, но нормально для интеграционных https://junit.org/junit5/docs/5.0.0/api/org/junit/jupiter/api/extension/ExtensionContext.Store.html
11) указание очередности тестов через @Order - полезно для тестирования отдельных шагов в интеграционном тесте. По умолчанию, кстати, тесты запускаются в алфавитном порядке https://www.baeldung.com/junit-5-test-order
В общем JUnit 5 догнал и перегнал TestNG, рекомендую к использованию если еще не пробовали.
#junit #unittests
Надеюсь все уже перешли на JUnit 5?
У JUnit 5 много крутых фич по сравнению с 4-й версией, например:
1) более удобная работа с параметризованными тестами через @ParametrizedTest, который вешается на метод - можно миксовать параметризированные и непараметризированные тесты в одном тестовом классе
2) возможность параметризировать не только входные параметры, но и все остальное в тесте с помощью динамически генерируемых тестов DynamicTests https://www.baeldung.com/junit5-dynamic-tests
3) есть возможность проверки исключений и таймаута через методы - assertThrows и assertTimeout. Это более правильно - assert идет после Act (я про Arrange-Act-Assert) и позволяет делать несколько проверок в одном тестовом методе
4) условное выполнение тестов в зависимости от среды: @EnabledOnOs, @EnabledOnJre, @EnabledIfSystemProperty, @EnabledIfEnvironmentVariable, также можно создавать свои условия
5) @RepeatedTest для повтора теста N раз
6) @DisplayName - полезно для задания говорящего имени теста для параметризированных тестов, к примеру
7) @Nested для складывания тестовых классов в "матрешку". Полезно, если у часть тестов нужно выполнить отнаследовавшись от базового класса
8) assertAll - объединение нескольких assert-ов в тесте. Полезно, как способ отключить fail fast режим проверок в JUnit - прогнать все assert-ы в тесте несмотря на падение одного из них.
9) ну и наконец механизм extensions. В 4-й версии был механизм Runner-ов, но его ограничение состояло в том, что на класс можно было повесить один Runner. А extensions может быть сколько угодно. Вот пример реализации BDD с помощью extension https://www.infoq.com/articles/deep-dive-junit5-extensions/ Здесь же есть пример 3-го способа параметризации теста - через ParameterResolver.
10) кроме всего прочего механизм extension добавляет store - контекст для обмена данными между тестами. Важно: для модульных тестов это антипаттерн, но нормально для интеграционных https://junit.org/junit5/docs/5.0.0/api/org/junit/jupiter/api/extension/ExtensionContext.Store.html
11) указание очередности тестов через @Order - полезно для тестирования отдельных шагов в интеграционном тесте. По умолчанию, кстати, тесты запускаются в алфавитном порядке https://www.baeldung.com/junit-5-test-order
В общем JUnit 5 догнал и перегнал TestNG, рекомендую к использованию если еще не пробовали.
#junit #unittests
Baeldung on Kotlin
Guide to Dynamic Tests in Junit 5 | Baeldung
Learn about dynamic tests introduced in JUnit 5 - a new programming model that supports full test lifecycle.
👍2
Всем привет!
Продолжим про антипаттерны в unit тестах.
Мы можем проверить в тесте метод на то, что он выбрасывает исключение.
В JUnit 5:
assertThrows(MyException.class, () -> myObject.myFunction(myString), "Expected myFunction() to throw, but it didn't");
и с помощью AssertJ:
assertThatExceptionOfType(MyException.class)
.isThrownBy(() -> { myObject.myFunction(myString); })
.withMessage("%s!", "boom")
.withMessageContaining("boom")
.withNoCause();
Это хорошая проверка, т.к. всегда нужно убедится, что выброшено именно то исключение, которое мы ожидаем. А иногда требуется проверить его параметры.
Но есть еще методы проверки, что исключения не было.
В JUnit 5:
assertDoesNotThrow(() -> myObject.myFunction(myString));
и AssertJ:
assertThatNoException()
.isThrownBy(() -> myObject.myFunction(myString));
А вот эти проверки выглядят излишними, т.к. выбрасывание исключения в любом случае прерывает тест, и он подсвечивается красным.
Возможно, если тест сложный и в нем много проверок - хочется локализовать место ошибки. Но в этом случае я бы задумался про разделение теста на несколько вместо использования assertDoesNotThrow. Опять же, в противном случае придется использовать данную проверку во всех тестах, кроме тех, что выбрасывают исключение. А это IMHO "замусоривает" код.
P.S. Интересный момент - библиотека Truth, о которой я писал ранее https://t.me/javaKotlinDevOps/51, вообще не содержит методов проверки на выбрасывание исключения, предлагая пользоваться соответствующим методом из JUnit, ведь assertThrows, описанный ранее, возвращает исключение:
val exception = assertThrows(MyException.class, () -> myObject.myFunction());
А уже его можно проверить более детально:
assertThat(exception)
.hasCauseThat()
.isInstanceOf(NumberFormatException.class);
assertThat(exception)
.hasMessageThat()
.startsWith("Bad");
Мне этот подход нравится.
#unittests #junit #assertj #truth #antipatterns
Продолжим про антипаттерны в unit тестах.
Мы можем проверить в тесте метод на то, что он выбрасывает исключение.
В JUnit 5:
assertThrows(MyException.class, () -> myObject.myFunction(myString), "Expected myFunction() to throw, but it didn't");
и с помощью AssertJ:
assertThatExceptionOfType(MyException.class)
.isThrownBy(() -> { myObject.myFunction(myString); })
.withMessage("%s!", "boom")
.withMessageContaining("boom")
.withNoCause();
Это хорошая проверка, т.к. всегда нужно убедится, что выброшено именно то исключение, которое мы ожидаем. А иногда требуется проверить его параметры.
Но есть еще методы проверки, что исключения не было.
В JUnit 5:
assertDoesNotThrow(() -> myObject.myFunction(myString));
и AssertJ:
assertThatNoException()
.isThrownBy(() -> myObject.myFunction(myString));
А вот эти проверки выглядят излишними, т.к. выбрасывание исключения в любом случае прерывает тест, и он подсвечивается красным.
Возможно, если тест сложный и в нем много проверок - хочется локализовать место ошибки. Но в этом случае я бы задумался про разделение теста на несколько вместо использования assertDoesNotThrow. Опять же, в противном случае придется использовать данную проверку во всех тестах, кроме тех, что выбрасывают исключение. А это IMHO "замусоривает" код.
P.S. Интересный момент - библиотека Truth, о которой я писал ранее https://t.me/javaKotlinDevOps/51, вообще не содержит методов проверки на выбрасывание исключения, предлагая пользоваться соответствующим методом из JUnit, ведь assertThrows, описанный ранее, возвращает исключение:
val exception = assertThrows(MyException.class, () -> myObject.myFunction());
А уже его можно проверить более детально:
assertThat(exception)
.hasCauseThat()
.isInstanceOf(NumberFormatException.class);
assertThat(exception)
.hasMessageThat()
.startsWith("Bad");
Мне этот подход нравится.
#unittests #junit #assertj #truth #antipatterns
Telegram
(java || kotlin) && devOps
Всем привет!
Не JUnit-ом единым...
Если говорить о фреймворках для unit тестирования все наверняка вспомнят JUnit и Mockito. Но есть ещё много чего полезного в этой области. Сегодня расскажу про библиотеки для улучшения читаемости проверок - assert. Про…
Не JUnit-ом единым...
Если говорить о фреймворках для unit тестирования все наверняка вспомнят JUnit и Mockito. Но есть ещё много чего полезного в этой области. Сегодня расскажу про библиотеки для улучшения читаемости проверок - assert. Про…
👍3
Рубрика: "Находки из Python"
Как вы думаете, что делает команда:
Ответ не очевиден (для меня): выводит 20 наиболее медленных тестов.
Вот так бы было более очевидно:
Второй вопрос: что меня в этом больше всего расстраивает?)
Ответ: то, что ни в Maven, ни в Gradle тестовых плагинах ничего такого нет. Хотя можно легко завайбкодить с помощью AI.
Если быть точным: в Gradle легко, в Maven придется плагин или внешний скрипт писать.
P.S. Еще такой же паттерн использует PostgreSQL -
#python #junit #unit_tests #python_gems
Как вы думаете, что делает команда:
uv run pytest --durations=20 ?Ответ не очевиден (для меня): выводит 20 наиболее медленных тестов.
Вот так бы было более очевидно:
uv run pytest --durations-min=1.0Второй вопрос: что меня в этом больше всего расстраивает?)
Ответ: то, что ни в Maven, ни в Gradle тестовых плагинах ничего такого нет. Хотя можно легко завайбкодить с помощью AI.
Если быть точным: в Gradle легко, в Maven придется плагин или внешний скрипт писать.
P.S. Еще такой же паттерн использует PostgreSQL -
FROM pg_stat_statements
ORDER BY total_exec_time DESC, а еще есть slow query log с фильтрацией по предельной длительности#python #junit #unit_tests #python_gems
И снова рубрика "Находки из Python".
Как вы думаете, что делает вот такая конструкция?
Она "фэйлит" прогон, если тест пройден)
Зачем это нужно - если из-за частичного рефакторинга некий код перестал работать. И нужно отследить момент починки в следующих релизах.
Т.е. как только чиним код - тест начинает падать, мы снимаем xfail.
Если тест просто "скипнуть" - это можно забыть сделать. Плюс если упала группа тестов - то ее можно пометить одинаковым описанием и убедится, что починились все. Стандартного функционала для этого нет, но можно поиском по проекту.
Видится, что полезно в плане контроля тестов.
Есть конечно радикальный вариант - вообще избегать отключения тестов, но жизнь - сложная штука).
Отдельно про параметр strict.
Если его поставить в false - получаем тест, который не ломает запуск ни при успешном прогоне, ни при падении.
Зачем это может быть нужно?
Для flaky тестов, которые невозможно починить здесь и сейчас.
Тут конечно у меня вопросики, т.к. такое действие - прямой путь к тому, что про flaky тест мы просто забудем.
А в итоге контроль над тестовым набором, наоборот, ухудшится.
Я сразу стал искать - есть ли аналог в Java?
В JUnit из коробки нет, иначе бы этого поста не было)
Но есть в JUnit Pioneer:
Это аналог strict режима. Не strict режима нет, что IMHO к лучшему.
Обе аннотации позволяют задать исключения, с которыми тест должен упасть.
Python вариант также позволяет задать condition:
В Python интерпретатор есть в runtime, в отличие от Java (там в runtime только компилятор из байт-кода в нативный), поэтому это проще сделать.
Мой вердикт - штука полезная.
#python #java #python_gems #unit_tests #junit
Как вы думаете, что делает вот такая конструкция?
@pytest.mark.xfail(strict=True, reason = "будет исправлено в задаче TASK-100")
def test_function():
Она "фэйлит" прогон, если тест пройден)
Зачем это нужно - если из-за частичного рефакторинга некий код перестал работать. И нужно отследить момент починки в следующих релизах.
Т.е. как только чиним код - тест начинает падать, мы снимаем xfail.
Если тест просто "скипнуть" - это можно забыть сделать. Плюс если упала группа тестов - то ее можно пометить одинаковым описанием и убедится, что починились все. Стандартного функционала для этого нет, но можно поиском по проекту.
Видится, что полезно в плане контроля тестов.
Есть конечно радикальный вариант - вообще избегать отключения тестов, но жизнь - сложная штука).
Отдельно про параметр strict.
Если его поставить в false - получаем тест, который не ломает запуск ни при успешном прогоне, ни при падении.
Зачем это может быть нужно?
Для flaky тестов, которые невозможно починить здесь и сейчас.
Тут конечно у меня вопросики, т.к. такое действие - прямой путь к тому, что про flaky тест мы просто забудем.
А в итоге контроль над тестовым набором, наоборот, ухудшится.
Я сразу стал искать - есть ли аналог в Java?
В JUnit из коробки нет, иначе бы этого поста не было)
Но есть в JUnit Pioneer:
@Test
@ExpectedToFail("будет исправлено в задаче TASK-100")
void testFunction() {
Это аналог strict режима. Не strict режима нет, что IMHO к лучшему.
Обе аннотации позволяют задать исключения, с которыми тест должен упасть.
Python вариант также позволяет задать condition:
@pytest.mark.xfail(condition="not config.getvalue('db')")
def test_function(): ...В Python интерпретатор есть в runtime, в отличие от Java (там в runtime только компилятор из байт-кода в нативный), поэтому это проще сделать.
Мой вердикт - штука полезная.
#python #java #python_gems #unit_tests #junit
🤩1💯1