240 записей с тегом "Тестирование"

1. Обзор​

В нашем предыдущем руководстве по @ConfigurationProperties мы узнали , как настроить и использовать аннотацию @ConfigurationProperties с Spring Boot для работы с внешней конфигурацией.

В этом руководстве мы обсудим, как тестировать классы конфигурации, которые полагаются на аннотацию @ConfigurationProperties , чтобы убедиться, что наши данные конфигурации загружены и правильно связаны с соответствующими полями.

2. Зависимости​

В нашем проекте Maven мы будем использовать зависимости spring-boot-starter и spring-boot-starter-test , чтобы включить основной API Spring и тестовый API Spring. Кроме того, мы будем использовать spring-boot-starter-validation в качестве зависимости проверки бина:

1. Обзор​

Модульное тестирование с помощью мок-фреймворка уже давно признано полезной практикой, и в последние годы на этом рынке доминирует фреймворк Mockito .

И чтобы упростить дизайн кода и сделать общедоступный API простым, некоторые желаемые функции были намеренно опущены. Однако в некоторых случаях эти недостатки вынуждают тестировщиков писать громоздкий код только для того, чтобы сделать возможным создание макетов.

Здесь в игру вступает фреймворк PowerMock .

PowerMockito — это API расширения PowerMock для поддержки Mockito. Он предоставляет возможности для работы с Java Reflection API простым способом для преодоления проблем Mockito, таких как отсутствие возможности имитировать окончательные, статические или частные методы.

В этом руководстве будет представлен API PowerMockito и рассмотрено его применение в тестах.

1. Обзор​

В этой статье мы рассмотрим, как мы можем проверить, что объект относится к определенному типу. Мы рассмотрим различные библиотеки тестирования и методы, которые они предлагают для утверждения типа объекта.

Сценарий, в котором нам может понадобиться это сделать, может быть разным. Распространенным является случай, когда мы используем интерфейс в качестве возвращаемого типа метода, но затем, в зависимости от возвращаемого конкретного объекта, мы хотим выполнять разные операции. Модульные тесты могут помочь нам определить , имеет ли возвращаемый объект тот класс, который мы ожидаем.

2. Пример сценария​

Давайте представим, что мы сортируем деревья по тому, сбрасывают ли они листья за зиму или нет. У нас есть два класса, Evergreen и Deciduous, оба реализуют интерфейс Tree . У нас есть простой сортировщик, который возвращает правильный тип в соответствии с именем дерева:

1. Обзор​

В этом коротком руководстве мы собираемся реализовать нестатические методы с аннотациями @BeforeAll и @AfterAll, доступными в Junit5 .

2. @BeforeAll и @AfterAll в нестатических методах​

Во время модульного тестирования мы можем иногда захотеть использовать @BeforeAll и @AfterAll в нестатических методах установки и демонтажа — например, в тестовом классе @ Nested или в качестве методов интерфейса по умолчанию.

Создадим тестовый класс с методами @BeforeAll и @AfterAll как нестатическими:

1. Введение​

Cucumber — это инструмент автоматизации тестирования, который поддерживает разработку, управляемую поведением (BDD). Он запускает спецификации, написанные в виде простого текста с синтаксисом Gherkin, который описывает поведение системы.

В этом руководстве мы рассмотрим несколько способов интеграции Cucumber с Gradle для запуска спецификаций BDD в рамках сборки проекта.

2. Настройка​

Во-первых, давайте настроим проект Gradle, используя Gradle Wrapper .

1. Обзор​

Когда мы тестируем методы, которые возвращают необязательные объекты, нам может понадобиться написать утверждения, которые либо проверяют, имеет ли необязательный объект значение, либо проверяют значение внутри него.

В этом коротком руководстве мы рассмотрим, как писать эти утверждения, используя функции как из JUnit , так и из AssertJ .

2. Проверьте, является ли необязательный параметр пустым или нет​

Если нам нужно только выяснить, имеет ли значение option значение, мы можем утверждать isPresent или isEmpty .

1. Обзор​

В наши дни Quarkus позволяет очень легко разрабатывать надежные и чистые приложения. Но как насчет тестирования?

В этом руководстве мы подробно рассмотрим, как можно протестировать приложение Quarkus . Мы изучим возможности тестирования, предлагаемые Quarkus, и представим такие концепции, как управление зависимостями и внедрение, имитация, конфигурация профиля и более конкретные вещи, такие как аннотации Quarkus и тестирование собственного исполняемого файла .

2. Настройка​

Начнем с базового проекта Quarkus, настроенного в нашем предыдущем руководстве по QuarkusIO .

Оглавление

• 1. Обзор
• 2. Слои
• 3. Мотивация и размытие границ юнит-теста
• 4. Заключение

1. Обзор​

Существует много способов протестировать сервисный уровень приложения. Цель этой статьи — показать один из способов изолированного модульного тестирования этого уровня, полностью имитируя взаимодействие с базой данных.

В этом примере будет использоваться Spring для внедрения зависимостей, JUnit, Hamcrest и Mockito для тестирования, но технологии могут различаться.

2. Слои ** **​

1. Обзор​

В этом кратком руководстве мы покажем, как интегрировать Mockito с моделью расширения JUnit 5. Чтобы узнать больше о модели расширения JUnit 5, ознакомьтесь с этой статьей .

Сначала мы покажем, как создать расширение, которое автоматически создает фиктивные объекты для любого атрибута класса или параметра метода, аннотированного @Mock .

Затем мы будем использовать наше расширение Mockito в тестовом классе JUnit 5.

2. Зависимости Maven​

1. Обзор​

В этой статье мы увидим, как мы можем перейти с JUnit 4 на последнюю версию JUnit 5 — с обзором различий между двумя версиями библиотеки.

Общие рекомендации по использованию JUnit 5 см. в нашей статье здесь .

2. Преимущества JUnit 5​

Начнем с предыдущей версии — JUnit 4 имеет ряд явных ограничений: