Зависимость тестов друг от друга в интеграционном тестировании
#1
Отправлено 19 декабря 2016 - 11:30
#2
Отправлено 19 декабря 2016 - 13:45
если у тебя тесты параллельные , то имплементация 2 врядли подойдет... нужен будет захардкоженный юзер
#3
Отправлено 19 декабря 2016 - 14:51
если у тебя тесты параллельные , то имплементация 2 врядли подойдет... нужен будет захардкоженный юзер
как будет больше тестов, буду параллелить конечно... в некоторых фреймворках можно указывать что параллелишь а что нет (в разных фреймворках конечно разные возможности по настройке распараллеливания)
хорошо конечно что при Варианте1 параллелить можно просто сразу всё и глобально, и настраивать что в каком потоке должно быть ничего не надо
#4
Отправлено 19 декабря 2016 - 17:40
Тест на логин и тест, для которого нужен логин - разные вещи. Если на логин затраты времени значительные, можно сделать контекст, который позволит не перелогиниваться между тестами в одном потоке. Но они будут зависеть не от теста с логином, а от этого контекста. наоборот, для теста на логин должен стоять признак, что предварительно надо разлогиниться. Зависимость здесь будет даже неудобна при построении логики фреймворка.
#5
Отправлено 19 декабря 2016 - 20:42
Тест на логин и тест, для которого нужен логин - разные вещи. Если на логин затраты времени значительные, можно сделать контекст, который позволит не перелогиниваться между тестами в одном потоке. Но они будут зависеть не от теста с логином, а от этого контекста. наоборот, для теста на логин должен стоять признак, что предварительно надо разлогиниться. Зависимость здесь будет даже неудобна при построении логики фреймворка.
смотри - тут был бы тест на логин который бы не зависел ни от кого, а все остальные тесты зависели бы от теста на логин
соответственно фреймворк строит граф зависимостей, видит что первым должен идти тест на логин и запускает его, а потом уже запускает все остальные тесты которые зависят от логина
(и поэтому тесту на логин не надо разлогиниваться ведь он идёт первый. а остальным тестам не надо логиниться так как логин уже совершён)
#6
Отправлено 19 декабря 2016 - 20:52
вроде нашёл решение, завтра опробую, отпишусь
#7
Отправлено 20 декабря 2016 - 07:29
Плюс зависимые тесты даже и не будут выполняться если тест от которого зависишь завалился, например тест "покупка" не будет выполняться если тест "логин" зафейлился - в результате получим более информативный отчёт где только тест "логин" будет зафейленным, а тест "покупка" будет помечен "пропущенным"
Это как раз основной недостаток такого подхода. Представьте что у Вас не 3 теста, а 10 или 100. При отказе первого, остальные 10 не выполнятся. Это по терминологии xUnit запах поведения: http://xunitpatterns...ratic Test.html
Плюс система не будет забиваться ненужными данными, типа нового юзера для каждого теста.
Почему бы не подчищать за собой после каждого теста? Можно реализовать независимые тесты и выполнять запуск параллельно.
#8
Отправлено 20 декабря 2016 - 07:42
Кстати говоря, в Вашем примере, зачем вообще нужно 3 теста, если все необходимые проверки выполнятся в последнем?
тест3, покупка:
создать юзеразалогинить юзерасделать покупку
#9
Отправлено 20 декабря 2016 - 07:56
Тест - это некоторая проверка требования или группы требований. Он независимый и может запускаться отдельно. То есть, мы захотели проверить некий набор требований - выбираем и запускаем нужные тесты. Захотели провести регрессию только по тестам с высоким приоритетом - запускаем только их. Если они будут тянуть за собой другие тесты - в отчете будет много лишнего. Например, мы запускаем 20 тестов, а в Jenkins или где-то еще 25 результатов. WTF???
Во фреймворке может быть общая процедура логина, и тесты могут ее переиспользовать. Но она не является тестом. Сам тест на логин может ее же вызывать, а потом делать какие-то дополнительные проверки, которые в других тестах повторять нет смысла, потому что они тестируют уже не логин. Ну, может быть, для логина проверять и не много, но потом где-нибудь такое объявится. А вы тесты целиком хотите затягивать в другие.
#10
Отправлено 20 декабря 2016 - 08:33
Плюс зависимые тесты даже и не будут выполняться если тест от которого зависишь завалился, например тест "покупка" не будет выполняться если тест "логин" зафейлился - в результате получим более информативный отчёт где только тест "логин" будет зафейленным, а тест "покупка" будет помечен "пропущенным"Это как раз основной недостаток такого подхода. Представьте что у Вас не 3 теста, а 10 или 100. При отказе первого, остальные 10 не выполнятся. Это по терминологии xUnit запах поведения: http://xunitpatterns...ratic Test.html
тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость
Плюс система не будет забиваться ненужными данными, типа нового юзера для каждого теста.Почему бы не подчищать за собой после каждого теста? Можно реализовать независимые тесты и выполнять запуск параллельно.
был бы и рад подчищать - но далеко не везде на уровне интеграционных тестов есть "подчистка". Например нет удаления пользователя - а только деактивация, есть отмена покупки но не её удаление
Кстати говоря, в Вашем примере, зачем вообще нужно 3 теста, если все необходимые проверки выполнятся в последнем?
Цитата
тест3, покупка:
создать юзеразалогинить юзерасделать покупку
необходимые проверки выполняются в каждом тесте. Например, проверки на регистрацию юзера - в "создать юзера". Какой смысл проверки регистрации юзера запихивать в "Покупку" например?
Ну, делать граф зависимостей тестов - это концептуально неверно.
это концептуально неверно только для юнит-тестов, а для интеграционных куча зависимостей всегда
Конечно удобно говорить про "независимость" тестов - а когда у тебя например сотни тестов, должен ли каждый тест создавать пользователя, добавлять в группы, регистрировать кредитку, класть деньги на кредитку и т.п. Вот тогда и приходится делать интеграционные тесты "зависимыми", чтобы один тест создал, другой залогинился, третий зарегистрировал кредитку и так далее
Захотели провести регрессию только по тестам с высоким приоритетом - запускаем только их. Если они будут тянуть за собой другие тесты - в отчете будет много лишнего. Например, мы запускаем 20 тестов, а в Jenkins или где-то еще 25 результатов. WTF???
гляну что там в Дженкинс получается. Но ведь всё равно даже когда запускаешь тест "только покупка" - он потянет за собой вызовы методов "регистрация" и "логин" всё равно, то есть как ни крутись, тест никак не "независимый", а только выглядит независимым в Дженкинсе
А вы тесты целиком хотите затягивать в другие.
тут не затягивать - а делать последовательность. Например один тест регистрирует пользователя, другой тест делает покупки, третий генерирует отчёт. Может быть удобно если эти три теста пойдут один за другим и переиспользуют уже созданные данные
#11
Отправлено 20 декабря 2016 - 08:40
тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость
Проблема решается небольшим набором Smoke-тестов на базовую функциональность и взаимодействие компонентов. Если хоть один из них не прошел, остальные тесты не запускаются.
#12
Отправлено 20 декабря 2016 - 08:51
Проблема решается небольшим набором Smoke-тестов на базовую функциональность и взаимодействие компонентов. Если хоть один из них не прошел, остальные тесты не запускаются.
Пример:
тест на пополнение кредитки не прошёл - значит можно не запускать покупки
тест на создание группы не прошёл - значит можно не запускать тесты на управления группами
следовательно:
можно тестировать группы несмотря на нерабочие кредитки. А смок сьют в этом случае ничего вообще не будет запускать, хотя тестировать другую часть системы можно
#13
Отправлено 20 декабря 2016 - 09:13
тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость
Не очень ясно. Не работает функционал логина, ок. Почему нельзя проверить исправления в модуле покупок?
Конечно удобно говорить про "независимость" тестов - а когда у тебя например сотни тестов, должен ли каждый тест создавать пользователя, добавлять в группы, регистрировать кредитку, класть деньги на кредитку и т.п. Вот тогда и приходится делать интеграционные тесты "зависимыми", чтобы один тест создал, другой залогинился, третий зарегистрировал кредитку и так далее
Не должен!
Хотите там создавать пользователя - создавайте, но не делайте из него тест.
На мой взгляд, для этого есть раздел предусловия - нужен такой-то пользователь.
#14
Отправлено 20 декабря 2016 - 09:54
тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость
Не очень ясно. Не работает функционал логина, ок. Почему нельзя проверить исправления в модуле покупок?
проверить конечно можно, тут вопрос только насколько тесты должны уметь "покупать без логина". Насколько реалистичны будут такие тесты?
Не должен!
Хотите там создавать пользователя - создавайте, но не делайте из него тест.
На мой взгляд, для этого есть раздел предусловия - нужен такой-то пользователь.
бывает что очень много предусловий, и некоторые уже можно выделить и в отдельные тесты. Пока создавал пользователя, логинился, добавлял кредитку, делал транзакции - вот уже и тесты прогнал
а ещё для разных тестов нужны разные предусловия - для одного нужен только созданный пользователь, для другого пользователь с кредиткой, для третьего с кредиткой и деньгами, для четвёртого ещё и с покупкой
#15
Отправлено 20 декабря 2016 - 10:04
а ещё для разных тестов нужны разные предусловия - для одного нужен только созданный пользователь, для другого пользователь с кредиткой, для третьего с кредиткой и деньгами, для четвёртого ещё и с покупкой
Да. А что вас в этом смущает?)
#16
Отправлено 20 декабря 2016 - 10:10
Все предусловия должны быть созданы ДО запуска тестов.
1. Для каких-то тестов должен быть заранее приготовлен набор разных пользователей.
2. При этом создание пользователей должно быть предметом отдельных тестов.
1 и 2 никак не должны влять друг на друга.
#17
Отправлено 20 декабря 2016 - 10:18
Все предусловия должны быть созданы ДО запуска тестов.
1. Для каких-то тестов должен быть заранее приготовлен набор разных пользователей.
2. При этом создание пользователей должно быть предметом отдельных тестов.
1 и 2 никак не должны влять друг на друга.
"2. При этом создание пользователей должно быть предметом отдельных тестов." - а кто решает должно ли это быть тестом или нет?
например для теста "права админа" создаётся "админ"
и ещё для теста "создание админа" опять создаётся "админ"
получается что можно один раз создать "админа" - в тесте "создание админа", и не создавать админа 2 раза
#18
Отправлено 20 декабря 2016 - 10:51
"2. При этом создание пользователей должно быть предметом отдельных тестов." - а кто решает должно ли это быть тестом или нет?
например для теста "права админа" создаётся "админ"
Создается, а не тестируется создание.
Сделайте запрос к БД на создание.
и ещё для теста "создание админа" опять создаётся "админ"
А вот тут проверяйте=)
#19
Отправлено 20 декабря 2016 - 10:56
Создается, а не тестируется создание.
Сделайте запрос к БД на создание.
А вот тут проверяйте=)
так получается что создадим как минимум двух админов, одного "просто создали", а другого "создали и проверили"
хотя можно было "создать и проверить" - создав одного админа, а не двух
идея такая чтобы не создавать те же самые данные по нескольку раз
#20
Отправлено 20 декабря 2016 - 12:31
нашёл что TestNG позиционируется как тул, у которого есть "зависимость тестов от тестов", и этим он лучше для интеграционного тестирования
попробовал, оказывается что сам TestNG да, работает с зависимостями тестов от тестов, можно настраивать цепочки и передавать параметры, всё прекрасно, зависимости собираются, граф строится автоматом, тестНГ разбирается кого каким порядком запустить, запускается на Дженкинсе и всё такое
НО! в Intellij Idea плагине для TestNG существует поддержка только dependsOnMethod, а у TestNG есть ограничение что эта зависимость должна быть только внутри класса. Вообще нереально держать все методы в одном классе, в одном файле
получается единственный способ в TestNG сделать зависимости тестов от тестов - это использование dependsOnGroups, а это оказывается не поддерживается в Intellij Idea плагине для TestNG!
баг уже заведён назад нашим человеком больше чем год назад, но до сих пор никакой реакции от JetBrains, им пофиг
вот в документации TestNG описание зависимостей тестов от тестов:
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных