Сообщений в теме: 26

[baxatob]

Расскажу, как у нас.

 

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

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

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

[Spock]

 

 

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

тоже хороший вариант, со своими достоинствами и недостатками

 

удобно что "всё сразу есть"

неудобно, что например надо поддерживать дамп при изменениях в базе. ну и сам дамп тоже поддерживать - например добавлять новых пользователей и роли в дамп когда в тесте требуется, удалять из дампа когда уже не требуются. Типа "удалил тест с user9. Но надо ли удалять user9 из дампа? Может кому нужен будет? А может нет?" Получается опять же что тесты зависят от создания базы. 

[Vasiliy]

 

 

 

Создается, а не тестируется создание.
Сделайте запрос к БД на создание.

 

 

А вот тут проверяйте=)

так получается что создадим как минимум двух админов, одного "просто создали", а другого "создали и проверили"

 

хотя можно было "создать и проверить" - создав одного админа, а не двух

 

идея такая чтобы не создавать те же самые данные по нескольку раз

 

Ну да, создали двух админов. Вам жалко?) Или в БД мало места?

На мой взгляд, у вас не совсем верное применение бритвы Оккама)

[Spock]

 

Ну да, создали двух админов. Вам жалко?) Или в БД мало места?

На мой взгляд, у вас не совсем верное применение бритвы Оккама)

это только для простенького примера "жили были два админа" :)

 

вот пример "более жизненный":

 

есть например система документооборота, возможно банковская либо другая финансовая, документы переводятся из одного статуса в другой с помощью джоба "закрытие дня", джоб крутится 5 минут

надо ввести 50 документов(например транзакций), прокрутить джоб и проверить каждый документ что правильный статус и дополнен правильными данными, и что сгенерились нужные транзакции, запустить генерацию отчёта и тоже проверить

 

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

[Spock]

а вот пример когда "жалко" создать пользователей, из реальной жизни

 

в системе которую тестирую: 

- создать пользователя очень быстро, например 500мс

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

- положить пользователю денег на кредитку - опять тот же гейтвей, ещё 5 секунд

 

получается что постоянное создание пользователей для обеспечения "независимых" тестов значительно увеличивает время выполнения сьюта

[Vasiliy]

Ясно.

Но в примере с 50 документами какие зависимости? Если вы не сможете создать 1 документ, то все равно будете закрывать день, так? Закрытие то надо проверить хоть на 50, хоть на 49?

[Spock]

 

Ясно.

Но в примере с 50 документами какие зависимости? Если вы не сможете создать 1 документ, то все равно будете закрывать день, так? Закрытие то надо проверить хоть на 50, хоть на 49?

если делать тесты без зависимостей - будут сплошные костыли

 

а с зависимостями будет типа:

- 50 тестов на создание по одному документу, у каждого своя личная группа "ввод документа такого-то", плюс общая группа "ввод документов"

- один тест "закрытие дня", софт зависимость от группы "ввод документов"

- 50 тестов на проверку каждого документа, у каждого своя личная хард-зависимость от "ввод документа такого-то", плюс общая хард-зависимость от "закрытие дня"

 

в результате пускаем тесты:

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

- потом после всех созданий и попыток созданий будет закрываться день

- потом начнутся проверки успешно созданных документов, проверки фейленных документов будут пропущены