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