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

1. Введение​

ReflectionTestUtils является частью среды Spring Test Context. Это коллекция служебных методов на основе отражения, используемых в модуле, и сценариев интеграционного тестирования для установки непубличных полей, вызова непубличных методов и внедрения зависимостей.

В этом руководстве мы рассмотрим, как мы можем использовать ReflectionTestUtils в модульном тестировании, рассмотрев несколько примеров.

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

Давайте начнем с добавления последних версий всех необходимых зависимостей, необходимых для наших примеров, в наш pom.xml :

1. Обзор​

При тестировании приложения Spring, основанного на уровне сохраняемости, таком как JPA, мы можем захотеть настроить источник тестовых данных для использования меньшей и более быстрой базы данных — той, которая отличается от той, которую мы используем для запуска приложения, — чтобы чтобы сделать наши тесты намного проще.

Настройка источника данных в Spring требует определения bean-компонента типа DataSource либо вручную, либо, при использовании Spring Boot, через стандартные свойства приложения.

В этом кратком руководстве мы рассмотрим несколько способов настройки отдельного источника данных для тестирования в Spring .

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

1. Введение​

REST-assured был разработан для упрощения тестирования и проверки REST API, и на него сильно повлияли методы тестирования, используемые в динамических языках, таких как Ruby и Groovy.

Библиотека имеет надежную поддержку HTTP, начиная, конечно, с глаголов и стандартных операций HTTP, но также выходит далеко за рамки этих основ.

В этом руководстве мы собираемся изучить REST-assured и будем использовать Hamcrest для утверждения. Если вы еще не знакомы с Hamcrest, вам следует сначала освежить в памяти учебник: Testing with Hamcrest .

Кроме того, чтобы узнать о более продвинутых вариантах использования REST-assured, ознакомьтесь с другими нашими статьями:

• Гарантия REST с Groovy
• Проверка схемы JSON с поддержкой REST
• Параметры, заголовки и файлы cookie с поддержкой REST

1. Введение​

В этом руководстве мы рассмотрим DBUnit, инструмент модульного тестирования, используемый для проверки взаимодействия реляционных баз данных в Java.

Мы увидим, как это поможет нам привести нашу базу данных в известное состояние и подтвердить ожидаемое состояние.

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

Во-первых, мы можем добавить DBUnit в наш проект из Maven Central, добавив зависимость dbunit к нашему pom.xml :

1. Обзор​

В этой быстрой статье мы рассмотрим концепцию контрактов, управляемых потребителями.

Мы будем тестировать интеграцию с внешней службой REST через контракт, который мы определяем с помощью библиотеки Pact . Этот контракт может быть определен клиентом, затем выбран провайдером и использован для разработки его услуг.

Мы также создадим тесты на основе контракта как для клиентского приложения, так и для провайдера.

2. Что такое пакт ?​

1. Обзор​

Mockito — популярный фреймворк для создания макетов для Java. Но прежде чем мы начнем, у нас есть несколько различных артефактов на выбор.

В этом кратком руководстве мы рассмотрим разницу между mockito-core и mockito-all . После этого мы сможем выбрать правильный.

2. мокито-ядро​

Артефакт mockito-core — главный артефакт Mockito. В частности, он содержит как API, так и реализацию библиотеки.

1. Обзор​

До JUnit 5, чтобы представить классную новую функцию, команда JUnit должна была сделать это с основным API. С JUnit 5 команда решила, что пришло время расширить возможности основного API JUnit за пределы самого JUnit, основная философия JUnit 5 называется « предпочитать точки расширения функциям ».

В этой статье мы сосредоточимся на одном из таких интерфейсов точек расширения — ParameterResolver , который можно использовать для ввода параметров в методы тестирования. Существует несколько различных способов сообщить платформе JUnit о вашем расширении (процесс, известный как «регистрация»), и в этой статье мы сосредоточимся на декларативной регистрации (т. е. регистрации через исходный код).

2. Разрешитель параметров​

Внедрение параметров в ваши методы тестирования можно было выполнить с помощью JUnit 4 API, но это было довольно ограничено. С помощью JUnit 5 API Jupiter можно расширить — за счет реализации ParameterResolver — для обслуживания объектов любого типа в ваших методах тестирования. Давайте посмотрим.

1. Обзор​

В этом кратком руководстве мы рассмотрим утверждения AssertJ, посвященные исключениям.

2. Без AssertJ​

Чтобы проверить, было ли выброшено исключение, нам нужно перехватить исключение, а затем выполнить утверждения:

try {
    // ...
} catch (Exception e) {
    // assertions
}

1. Введение​

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

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

2. Сопоставление значений аргументов​

Следующие подходы применимы как к ожиданиям , так и к проверкам .

1. Обзор​

В этой статье основное внимание будет уделено тестированию службы REST с несколькими типами/представлениями мультимедиа.

Мы напишем интеграционные тесты, способные переключаться между несколькими типами представлений, поддерживаемыми API. Цель состоит в том, чтобы иметь возможность запускать один и тот же тест, используя те же самые URI службы, просто запрашивая другой тип носителя.

2. Цели​

Любой REST API должен предоставлять свои ресурсы как представления с использованием одного или нескольких типов мультимедиа. Клиент установит заголовок Accept , чтобы выбрать тип представления, который он запрашивает у службы.