Выполнение предусловия для тестов: тесты или SQL?

общие вопросы
, , ,
#1

Здравствуйте! Ситуация такова:

Есть тесты:
Добавление группы пользователей
Добавление пользователя
Добавление прав доступа для пользователя/группы пользователей

У нас есть отдельный тест на создание группы пользователей, отдельный тест на создание пользователя.
Далее, при написании теста на проверку прав доступа, нам нужно выполнить предусловие: должна быть группа пользователей и два пользователя этой группы.
Его можно сделать двумя способами:

  1. С помощью тестов на добавление пользователя и группы создаем всё, что нужно и сколько нужно
  2. С помощью SQL запросов.

Плюсы SQL:
С помощью SQL выполнение предусловия проходит быстрее;
Тесты становятся более независимыми;
Минусы:
Нужно хорошо знать БД и все взаимосвязи
При изменении логики добавления или БД, надо уже будет править SQL запросы

Дилемма: что выбрать? Посоветуйте, пожалуйста, поделитесь опытом.

#2
  • Делегировать написание / саппорт SQL скрипта девелоперам, которые в курсе структуры БД и всех изменений.
  • Дергать этот скрипт в качестве прекондишена.
  • Не забывать подчищать за собой, когда группы / пользователи уже не нужны.
1 лайк
#3

Здравствуйте!
Я бы делал через sql, по тем же причинам что Вы указали в своем посте. Ничего плохого в изменении поведения нет - это вполне рабочий момент. Я обычно вообще переиспользую даошки прямо из кода для общения с базой. Кроме того, я бы использовал эти дао в тестах не напрямую, а через некий сервис с интерфейсом, содержащим методы для полного или частичного конфигурирования приложения для той или иной ситуации.

1 лайк
#4

Третий способ упустили - API, а он точно должен быть.

1 лайк
#5

Нужно рассматривать каждый конкретный вариант и взвешивать соотношение факторов:

  • время выполнения (чем быстрее, тем лучше)
  • сложность реализации (чем проще реализовать и поддерживать, тем лучше)
  • частота использования (чем в большем количестве мест применяется, тем предпочтительней скрипты)

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

К примеру:

  • вам достаточно заинсертить одну строку в одну таблицу и юзер готов - очевидно скрипты будут предпочтительны
  • через ui вам достаточно в рамках одной формы ввести перечень инпутов и нажать сейв, а через скрипты вам понадобится инсертить в несколько таблиц - если данные связи в базе для вас предельно ясны, то и в этом случае можно выбрать скрипты, но тут есть риск что будут добавляться новые фичи, структура будет усложняться, в проект придут новые люди и понимание как это работало/работает, и вообще зачем, потеряется. Так что тут я бы смотрел на масштабы, как часто, в скольких местах вам придется осуществлять этот престеп, чем чаще - тем больше плюсов в сторону скриптов, если в паре мест, можно и через ui сделать, абсолютно без риска
1 лайк
#6

Спасибо большое за развернутый ответ, все плюсы и минусы)

#7

Спасибо за ответ! Не подскажете, что значит “даошки”?)

#8

DAO - data access object - это объект предоставляющий интерфейс для работы с базой. Попробуйте в коде своего проекта поискать классы содержащие эту аббривеатуру и подергать своих девелоперов чтобы объяснили.
В самом обобщенном виде структура такая: есть таблица, скажем, “Users”; в коде представлением этой таблицы является класс UsersDTO (DTO = Data Transfer Object) - этот класс содержит все поля из таблицы плюс методы дотупа к ним; связующим звеном между ними является класс UsersDAO. Например, для сохранения объектов в нем может быть метод с сигнатурой “UsersDTO save(UsersDTO user)”.

1 лайк
#9

DTO = data transfer object

#10

Верно, спасибо за замечание. Подправил свой пост.

#12

Для прекондишенов я бы использовал SQL.
1). Полезно знать о изменении структуры базы - может служить источником для дополнительных тестов. Завалившийся прекондишен даст Вам это знание.
2). По сути, запустив тест перед тестом, Вы делаете свой тест зависимым. Таким образом, если внезапно что-нить поменяется на форме создания нового юзера - Ваш тест на изменение прав доступа не запустится, даже если на форме с правами никаких изменений не произошло. Таким образом, Вы снижаете информативность Ваших тестов.
3). UI тесты по своему характеру менее стабильны, поскольку зависят от большего кол-ва вещей, нежели юнит тесты или интеграционные тесты (наличие связи с базой, наличие связи с app server, браузер может крашнуться и т.д.). Запустив UI тест как прекондишен, Вы уменьшаете стабильность тестов.
4). Прекондишен, выполненный на SQL, отработает гораздо быстрее, чем через UI.
5). Как вариант, можете использовать фабрики для выполнения прекондишенов - таким образом Вы сможете инкапсулировать логику создания юзеров, не особо потеряв при этом в скорости. Более того, если в Вашем проекте есть юнит тесты - то фабрики, скорее всего, уже готовы, Вам останется только их использовать. А задачи по поддержке логики работы фабрик лягут на разработчиков, поскольку они и так их используют.

1 лайк