Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Автоматизировать CRUD-тестирование можно несколькими способами. Как минимум нужно проверить по одной операции из каждого раздела: создание, чтение, обновление и удаление. Для удобства давайте предположим, что:

1. Мы тестируем простое текстовое поле, которое использовали раньше.
2. Мы автоматизируем на уровне UI (автоматизацию API я буду обсуждать в других статьях).

Вот шаблон, которым я пользуюсь для тестирования CRUD. Для простоты я пишу в Specflow/Cucumber:

Сценарий: добавление пользователя.

ЕСЛИ я добавляю пользователя

КОГДА я добавляю имя и сохраняю

ТОГДА я перехожу к странице пользователей

И убеждаюсь, что новое имя добавлено.

Сценарий: обновление пользователя.

ЕСЛИ я обновляю пользователя

КОГДА я обновляю имя и сохраняю

ТОГДА я перехожу к странице пользователей

И я убеждаюсь, что имя обновлено.

Сценарий: удаление пользователя.

ЕСЛИ я удаляю пользователя

КОГДА я удаляю имя и сохраняю

ТОГДА я перехожу к странице пользователей

И убеждаюсь, что этого имени там нет.

Эти три теста проверят создание, обновление и удаление. Первые два также проверяют чтение, потому что мы проверяем пользователя для наших утверждений. Следовательно, этими тремя тестами я покрыла базовую функциональность CRUD.

Тут можно возразить, что эти тесты не индемпотентны. Индемпотентность означает, что тест можно прогонять снова и снова с теми же результатами. Я не могу многократно прогонять третий тест и получать те же результаты, потому что после первого же прогона пользователь перестанет существовать, и некого будет удалять.

Если мы хотим решить эту проблему, тест можно составить так.

Сценарий: CRUD-тестирование пользователя.

ЕСЛИ я тестирую CRUD

КОГДА я добавляю имя и сохраняю

И убеждаюсь, что имя сохранено

КОГДА я меняю имя и сохраняю

И я убеждаюсь, что имя обновлено

КОГДА я удаляю имя и сохраняю

ТОГДА я убеждаюсь, что имя удалено.

Этот сценарий тестирует всю CRUD-функциональность формы. Однако у него три разных утверждения. Я предпочитаю, чтобы в моих UI-тестах было не более двух.

Если рассматривать мои три исходных сценария как группу, то совместно они индемпотентны. Мои тесты отвечают за создание и удаление моих данных.

Хорошая идея – проверить некоторые негативные сценарии, например, создать пользователя с невалидным именем, и обновить пользователя с невалидным именем. Эти тесты могут выглядеть так:

Сценарий: создание пользователя с невалидным именем.

ЕСЛИ я добавляю нового пользователя

КОГДА я ввожу невалидное имя и сохраняю

ТОГДА я убеждаюсь, что получаю правильное сообщение об ошибке на странице.

И перехожу к странице пользователей

И убеждаюсь, что пользователь не добавлен.

Сценарий: обновление пользователя с невалидным именем.

ЕСЛИ я обновляю существующего пользователя

КОГДА я обновляю имя невалидным значением и сохраняю

ТОГДА я убеждаюсь, что получаю правильное сообщение об ошибке на странице.

И перехожу к странице пользователей

И убеждаюсь, что существующее имя не изменилось.

Первый сценарий индемпотентен, потому что в базу данных ничего не добавляется. Второй сценарий тоже индемпотентен, но требует существования пользователя. Мы можем предположить, что наш пользователь всегда будет существовать, но если кто-то его случайно удалит, тест упадет. В этом случае неплохо бы добавить предварительный шаг и заключительный шаг – они будут создавать пользователя в начале теста и удалять его, когда тест-набор завершен.

Эти пять сценариев – три для "счастливого пути" и два негативных – составят отличный регресс-набор для нашей простенькой формы. Это очень простая форма, на ней всего одно поле – не очень реалистичный сценарий, однако неплохой способ поразмышлять о шаблонах автоматизированных UI-тестов.

Обсудить в форуме