Перейти к основному содержимому

Введение в ZeroCode

· 6 мин. чтения

1. Обзор​

В этой статье мы представим среду автоматизированного тестирования ZeroCode . Мы изучим основы на примере тестирования REST API.

2. Подход​

Фреймворк ZeroCode использует следующие подходы:

  • Многогранная поддержка тестирования
  • Декларативный стиль тестирования

Давайте обсудим их обоих.

2.1. Многогранная поддержка тестирования​

Платформа предназначена для поддержки автоматизированного тестирования нескольких аспектов наших приложений. Среди прочего, это дает нам возможность протестировать:

  • ОТДЫХАТЬ
  • МЫЛО
  • Безопасность
  • Нагрузка/стресс
  • База данных
  • Апач Кафка
  • ГрафQL
  • Спецификации открытого API

Тестирование выполняется через DSL фреймворка, который мы вскоре обсудим.

2.2. Декларативный стиль​

ZeroCode использует декларативный стиль тестирования, что означает, что нам не нужно писать фактический код тестирования. Мы объявляем сценарии в файлах JSON/YAML, а фреймворк «переводит» их в тестовый код за кулисами. Это помогает нам сконцентрироваться на том, что мы хотим протестировать, а не на том, как это тестировать .

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

Давайте добавим зависимость Maven в наш файл pom.xml :

<dependency>
      <groupId>org.jsmart</groupId>
      <artifactId>zerocode-tdd</artifactId>
      <version>1.3.27</version>
      <scope>test</scope>
 </dependency>

Последняя версия доступна на Maven Central . Мы также можем использовать Gradle. Если мы используем IntelliJ, мы можем загрузить плагин ZeroCode с Jetbrains Marketplace .

4. Тестирование REST API​

Как мы уже говорили выше, ZeroCode может поддерживать тестирование нескольких частей наших приложений. В этой статье мы сосредоточимся на тестировании REST API. По этой причине мы создадим небольшое веб-приложение Spring Boot и предоставим одну конечную точку:

@PostMapping
public ResponseEntity create(@RequestBody User user) {
    if (!StringUtils.hasText(user.getFirstName())) {
        return new ResponseEntity("firstName can't be empty!", HttpStatus.BAD_REQUEST);
    }
    if (!StringUtils.hasText(user.getLastName())) {
        return new ResponseEntity("lastName can't be empty!", HttpStatus.BAD_REQUEST);
    }
    user.setId(UUID.randomUUID().toString());
    users.add(user);
    return new ResponseEntity(user, HttpStatus.CREATED);
}

Давайте посмотрим на класс User , на который ссылается наш контроллер:

public class User {
    private String id;
    private String firstName;
    private String lastName;

    // standard getters and setters
}

Когда мы создаем пользователя, мы устанавливаем уникальный идентификатор и возвращаем весь объект пользователя обратно клиенту. Конечная точка доступна по пути /api/users . Мы будем сохранять пользователей в памяти, чтобы упростить задачу.

5. Написание сценария​

Сценарий играет центральную роль в ZeroCode. Он состоит из одного или нескольких шагов, которые мы и хотим протестировать. Давайте напишем сценарий с одним шагом, который проверяет успешный путь создания пользователя:

{
  "scenarioName": "test user creation endpoint",
  "steps": [
    {
      "name": "test_successful_creation",
      "url": "/api/users",
      "method": "POST",
      "request": {
        "body": {
          "firstName": "John",
          "lastName": "Doe"
        }
      },
      "verify": {
        "status": 201,
        "body": {
          "id": "$NOT.NULL",
          "firstName": "John",
          "lastName": "Doe"
        }
      }
    }
  ]
}

Давайте объясним, что представляет собой каждое из свойств:

  • scriptName — это имя сценария; мы можем использовать любое имя, которое мы хотим

  • steps — массив объектов JSON, где мы описываем, что хотим протестировать

  • name — имя, которое мы даем шагу

  • url – относительный URL конечной точки; мы также можем указать абсолютный URL-адрес, но, как правило, это не очень хорошая идея

  • метод — HTTP-метод

  • запрос — HTTP-запрос

  • body – тело HTTP-запроса

  • Verify — здесь мы проверяем/утверждаем ответ, который вернул сервер

  • status — код состояния ответа HTTP

  • body (внутри свойства verify) — тело ответа HTTP

На этом этапе мы проверяем, успешно ли создан пользователь. Мы проверяем значения firstName и lastName , которые возвращает сервер. Кроме того, мы проверяем, что идентификатор не равен нулю , с помощью токена утверждения ZeroCode.

Как правило, у нас есть более одного шага в сценариях. Давайте добавим еще один шаг в массив шагов нашего сценария: 

{
  "name": "test_firstname_validation",
  "url": "/api/users",
  "method": "POST",
  "request": {
    "body": {
      "firstName": "",
      "lastName": "Doe"
    }
  },
  "verify": {
    "status": 400,
    "rawBody": "firstName can't be empty!"
  }
}

На этом шаге мы указываем пустое имя, что должно привести к неправильному запросу. Здесь тело ответа не будет в формате JSON, поэтому мы используем свойство rawbody , чтобы сослаться на него как на простую строку.

ZeroCode не может напрямую запускать сценарий — для этого нам нужен соответствующий тест-кейс.

6. Написание тестового примера​

Чтобы выполнить наш сценарий, давайте напишем соответствующий тестовый пример:

@RunWith(ZeroCodeUnitRunner.class)
@TargetEnv("rest_api.properties")
public class UserEndpointIT {

    @Test
    @Scenario("rest/user_create_test.json")
    public void test_user_creation_endpoint() {
    }
}

Здесь мы объявляем метод и помечаем его как тест, используя аннотацию @Test из JUnit 4. Мы можем использовать JUnit 5 с ZeroCode только для нагрузочного тестирования.

Мы также указываем расположение нашего сценария с помощью аннотации @Scenario , которая исходит из фреймворка ZeroCode. Тело метода пустое. Как мы уже говорили, мы не пишем реальный тестовый код. То, что мы хотим протестировать, описано в нашем сценарии. Мы просто ссылаемся на сценарий в методе тестового примера. Наш класс UserEndpointIT имеет две аннотации:

  • @RunWith — здесь мы указываем, какой класс ZeroCode отвечает за выполнение наших сценариев.
  • @TargetEnv — указывает на файл свойств, который будет использоваться при запуске нашего сценария.

Когда мы объявили свойство url выше, мы указали относительный путь. Очевидно, что фреймворку ZeroCode нужен абсолютный путь, поэтому мы создаем файл rest_api.properties с несколькими свойствами, которые определяют, как должен выполняться наш тест:

  • web.application.endpoint.host — хост REST API; В нашем случае это http://localhost.
  • web.application.endpoint.port — порт сервера приложений, на котором выставлен наш REST API; В нашем случае это 8080
  • web.application.endpoint.context — контекст API; в нашем случае он пустой

Свойства, которые мы объявляем в файле свойств, зависят от того, какое тестирование мы проводим. Например, если мы хотим протестировать производителя/потребителя Kafka , у нас будут разные свойства.

7. Выполнение теста​

Мы создали сценарий, файл свойств и тестовый пример. Теперь мы готовы запустить наш тест. Поскольку ZeroCode — это инструмент интеграционного тестирования, мы можем использовать отказоустойчивый плагин Maven:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>3.0.0-M5</version>
    <dependencies>
        <dependency>
            <groupId>org.apache.maven.surefire</groupId>
            <artifactId>surefire-junit47</artifactId>
            <version>3.0.0-M5</version>
        </dependency>
    </dependencies>
    <executions>
        <execution>
            <goals>
                <goal>integration-test</goal>
                <goal>verify</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Для запуска теста мы можем использовать следующую команду:

mvn verify -Dskip.it=false

`ZeroCode создает несколько типов журналов, которые мы можем проверить в папке ${project.basedir}/target .`

8. Заключение​

В этой статье мы рассмотрели среду автоматизированного тестирования ZeroCode. Мы показали, как работает фреймворк на примере тестирования REST API. Мы также узнали, что ZeroCode DSL устраняет необходимость написания фактического кода для тестирования.

Как всегда, исходный код статьи доступен на GitHub .