хорошие тесты нельзя построить без независимых данных.
как минимум должно действовать правильно - данные которые использовались один раз не могут быть использованы второй раз.
но в реальности тяжело придерживаться таких правил, делать очистку БД перед каждым прогоном, выполнять роллбеки и т.д.
можно конечно еще генерировать уникальные данные, как один из вариантов решения.
а как вы решаeте вопрос независимости данных для ваших тестов?
а Вы имеете ввиду даные типо локаторов или например какие то данные для тестов для прогонки ?
как минимум должно действовать правильно - данные которые использовались один раз не могут быть использованы второй раз.
а почему?
Например, если мы берем какой-нибудь аккаунт для прогона теста1 (например создания платежа).
Мы можем взять тот же аккаунт для прогона теста2 (например отправка почты) при условии что аккаунт подходит требованиям теста (например, имеет валидный e-mail).
Кроме того, если тест1 каким-нибудь образом неправильно изменил аккаунт (а тест проверят детали платежа, а не аккаунта), то тест2 или любой другой, который ориентируется на детали аккаунта сможет поймать эту проблему.
У нас была похожая ситуация когда через веб-интерфейс неправильно проставлялся адресс клиента при платеже и другой тест через десктоп-интерфейс поймал эту проблему, так как не мог найти данного клиента через адресс.
В целом, идея такова - что раз мы работаем с данными через пользовательский UI - значит данные изменяются так же, как изменялись бы реальными пользователями, а значит их можно и нужно использовать.
Тесты достают данные по критериям из БД - если таких нету, сами создаем.
Ну и раз в эн времени делаем очистку БД из бэкапа.
я например для автоматизации одной из систем тоже использую хард коды в аккаунтах и прочих вещах)
Мы можем взять тот же аккаунт для прогона теста2 (например отправка почты) при условии что аккаунт подходит требованиям теста (например, имеет валидный e-mail).
Кроме того, если тест1 каким-нибудь образом неправильно изменил аккаунт (а тест проверят детали платежа, а не аккаунта), то тест2 или любой другой, который ориентируется на детали аккаунта сможет поймать эту проблему.
Вот именно для того, чтобы у вас не было таких проблем (тест1 что-то сделал с данными из-за чего сломался тест2) и нужно делать тесты независимыми от данных.
В конкретно вашем случае у вас схема неправильная - все необходимые ассерты должны быть прямо в тест1
В моем случае тесты запускаются на инстансе, который содержит определенный набор данных, тесты выполняется в специальном режиме, при котором изменения в базе не коммитятся, они выполняются в рамках текущей транзакции и после завершения сессии отменяются (этот механизм реализован в недрах нашего приложения именно для тестовых целей).
В общем вопрос довольно интересный, на предыдущих проектах отталкивался от того, что тесты должны создавать себе самостоятельно необходимые данные, если это не очень трудозатратная процедура (по сути это блок предварительных условий, который нужно выполнить перед началом выполнения теста - как ручного, так и автоматизированного). При этом все создаваемые объекты создавались с уникальными именами, чтобы избежать пересечения с объектами, созданными ранее при предыдущих запусках тестов.
Возможно, я не смог неправильно объяснить схему.
тест1 работал с данными только через пользовательский интерфейс.
Соответственно поломка тест2 "правильная" - из-за бага в приложении.
И ассерты данных пользователя для тест1 НЕ необходимые - это я пытался сообщить. Хотя это довольно частный случай, но именно это и произошло на практике.
1. Ручной запуск тестов
В этом режиме используем заранее подготовленную базу данных. Если для теста нужны данные, то они создаются в блоке GIVEN. После завершеня эти данные удаляются. Т.е каждый тест вначале создает данные, потом их удаляется. Все данные при этом еще имеют уникальные имена.
2. Автоматический запуск тестов.
Работа каждого теста такая же как и при ручном. Основное отличие в том что перед началом прогона тестов подымается тестовое окружение (создание БД, обновление сервисов, публикация клиента.)
P.S. У нас клиент серверное приложение (WPF, WCF, MSSQL)
данные для тестов
ну хорошо, предположим у вас есть 100 тестов
от аккаунта 1 у вас зависит 50 тестов.
предположим у вас проганяется 20й тест и вы ламаете аккаунт 1, соответственно остальные 30 тестов покажут файл по одной и той же причине
а ведь цель функциональных тестов - это проверка конкретной функциональности, а получается что один баг закрывает нам возможность проверки другой функциональности
вместо этого мы будем тратить время на фикс багов и только потом уже сможем прогнать остальные 30 тестов
НО причина в данных, а нужно проверять функциональность
я уже не раз слышал об таком подходе, к сожалению, не удалось его попробывать, так как разработчики должны сделать соответствующую среду
иначе управление транзакциями может оказаться тяжелой задачей
а сколько у вас тестов? и как быстро поднимается ваше окружение?
самый большой минус, если у вас зависимость - это сложность параллелизации тестов
как только надо будет решать этот вопрос, зависимые тесты сразу станут "комом в горле"
Мы генерируем уникальные имена. Дешевый и простой способ, хотя может быть не применим в некоторых случаях.
Базу чистим один раз перед запуском всех тестов.
Для экономии времени данные после выполнения тестов не удаляем, если они не должны мешать другим тестам.
Также для экономии времени данные и предусловия создаем не для каждого теста, а для группы тестов.
testomat.io управление авто тестами