Обычно мы выполняем тесты во время сборки Maven с помощью плагина Maven surefire .
В этом руководстве будет показано, как использовать этот плагин для запуска одного тестового класса или тестового метода.
Плагин Maven surefire прост в использовании. У него только одна цель: проверить .
Иногда при написании модульных тестов нам нужно сделать независимое от порядка сравнение списков. В этом коротком руководстве мы рассмотрим различные примеры написания таких модульных тестов.
Согласно документации Java List#equals , два списка равны, если они содержат одни и те же элементы в одном и том же порядке. Следовательно, мы не можем просто использовать метод equals , так как мы хотим выполнять независимое от порядка сравнение.
В этом руководстве мы будем использовать эти три списка в качестве примеров входных данных для наших тестов:
В этой статье мы узнаем, как исправить ошибки JUnit NoSuchMethodError и NoClassDefFoundError . Такие проблемы обычно возникают, когда у нас есть две разные версии JUnit в нашем пути к классам . Такая ситуация может возникнуть, например, когда версия JUnit проекта отличается от той, которая используется в зависимости Maven или Gradle.
NoClassDefFoundError в проекте SpringДопустим, у нас есть проект Maven, использующий Spring Boot 2.1.2 и зависимость Spring Boot Starter Test . С такой зависимостью мы можем писать и запускать автоматические тесты, используя JUnit 5.3.2, который является JUnit-версией зависимости spring-boot-test .
Теперь предположим, что мы продолжим использовать Spring Boot 2.1.2. Однако мы хотим использовать JUnit 5.7.1. Возможным подходом было бы включение зависимостей junit-jupiter-api , junit-jupiter-params , junit-jupiter-engine и junit-platform-launcher в наш файл pom.xml :
В этом руководстве мы покажем, как мы можем использовать выражения тега Cucumber для управления выполнением тестов и их соответствующими настройками.
Мы рассмотрим, как мы можем разделить наши тесты API и пользовательского интерфейса и контролировать, какие шаги конфигурации мы выполняем для каждого из них.
Наш пример приложения имеет простой пользовательский интерфейс для генерации случайного числа между диапазоном значений:
В этом руководстве мы покажем, как мы можем предотвратить запуск bean-компонентов типа ApplicationRunner или CommandLineRunner во время интеграционных тестов Spring Boot.
Наш пример приложения состоит из запуска командной строки, запуска приложения и bean-компонента службы задач.
Запуск командной строки вызывает метод выполнения службы задач , чтобы выполнить задачу при запуске приложения:
Иногда при написании модульных тестов нам может понадобиться протестировать код, напрямую взаимодействующий с классом System . Обычно в таких приложениях, как инструменты командной строки, которые вызывают System.exit напрямую или считывают аргументы с помощью System.in .
В этом руководстве мы рассмотрим наиболее распространенные функции аккуратной внешней библиотеки под названием System Rules , которая предоставляет набор правил JUnit для тестирования кода, использующего класс System .
Во-первых, давайте добавим зависимость System Rules к нашему pom.xml :
In this article, we'll show how to check the architecture of a system using ArchUnit .
ArchUnit?The link between architecture traits and maintainability is a well-studied topic in the software industry. Defining a sound architecture for our systems is not enough, though. We need to verify that the code implemented adheres to it.
Simply put, ArchUnit is a test library that allows us to verify that an application adheres to a given set of architectural rules . But, what is an architectural rule? Even more, what do we mean by architecture in this context?
При модульном тестировании мы можем иногда захотеть протестировать сообщения, которые мы пишем в стандартный вывод через System.out.println() .
Хотя обычно мы предпочитаем структуру протоколирования прямому взаимодействию со стандартным выводом, иногда это невозможно.
В этом кратком руководстве мы рассмотрим несколько способов модульного тестирования System.out.println() с помощью JUnit .