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

[Spock]

Требования: 

 

например надо сделать три теста:

1. создать юзера

2. залогинить юзера

3. сделать покупку

 

 

Имплементация, вариант 1, с гранулярными (независимыми) тестами:

 

тест1, создание юзера: 

создать юзера

 

тест2, логин юзера:

создать юзера

залогинить юзера

 

тест3, покупка:

создать юзера

залогинить юзера

сделать покупку

 

 

Имплементация, вариант 2, с зависимыми тестами:

 

тест1, создание юзера: 

создать юзера

передать юзера в контекст

 

тест2, логин юзера (зависит от тест1)

получить юзера из контекста

залогинить юзера

 

тест3, покупка (зависит от тест2)

получить юзера из контекста

сделать покупку

 

 

 

Второй вариант конечно заманчивый - тесты будут выполняться значительно быстрее, так как каждый раз не надо создавать тестовые данные, можно выстраивать цепочки. Плюс система не будет забиваться ненужными данными, типа нового юзера для каждого теста. Плюс зависимые тесты даже и не будут выполняться если тест от которого зависишь завалился, например тест "покупка" не будет выполняться если тест "логин" зафейлился - в результате получим более информативный отчёт где только тест "логин" будет зафейленным, а тест "покупка" будет помечен "пропущенным"

 

Пишу интеграционные тесты на Java, реально ли на каком-нибудь фреймворке сделать подобные зависимости? Конечно граф зависимостей должен строиться автоматически. Например при запуске только "тест3" фреймворк должен рассчитать граф и запусить сначала "тест1", затем "тест2" а потом "тест3". А может не нужны эти зависимости, и тесты должны быть гранулярными? Или ещё как? Может что полезное есть в других языках?

[Lzk]

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

[Spock]

 

 

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

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

 

хорошо конечно что при Варианте1 параллелить можно просто сразу всё и глобально, и настраивать что в каком потоке должно быть ничего не надо

[checo]

Тест на логин и тест, для которого нужен логин - разные вещи. Если на логин затраты времени значительные, можно сделать контекст, который позволит не перелогиниваться между тестами в одном потоке. Но они будут зависеть не от теста с логином, а от этого контекста. наоборот, для теста на логин должен стоять признак, что предварительно надо разлогиниться. Зависимость здесь будет даже неудобна при построении логики фреймворка.

[Spock]

 

 

Тест на логин и тест, для которого нужен логин - разные вещи. Если на логин затраты времени значительные, можно сделать контекст, который позволит не перелогиниваться между тестами в одном потоке. Но они будут зависеть не от теста с логином, а от этого контекста. наоборот, для теста на логин должен стоять признак, что предварительно надо разлогиниться. Зависимость здесь будет даже неудобна при построении логики фреймворка.

смотри - тут был бы тест на логин который бы не зависел ни от кого, а все остальные тесты зависели бы от теста на логин

 

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

(и поэтому тесту на логин не надо разлогиниваться ведь он идёт первый. а остальным тестам не надо логиниться так как логин уже совершён)

[Spock]

вроде нашёл решение, завтра опробую, отпишусь

[dimaska2710]

 

 

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

Это как раз основной недостаток такого подхода. Представьте что у Вас не 3 теста, а 10 или 100. При отказе первого, остальные 10 не выполнятся. Это по терминологии xUnit запах поведения: http://xunitpatterns...ratic Test.html

 

 

 

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

Почему бы не подчищать за собой после каждого теста? Можно реализовать независимые тесты и выполнять запуск параллельно. 

[dimaska2710]

Кстати говоря, в Вашем примере, зачем вообще нужно 3 теста, если все необходимые проверки выполнятся в последнем?

 

тест3, покупка:

создать юзера

залогинить юзера

сделать покупку

[checo]

Ну, делать граф зависимостей тестов - это концептуально неверно.
Тест - это некоторая проверка требования или группы требований. Он независимый и может запускаться отдельно. То есть, мы захотели проверить некий набор требований - выбираем и запускаем нужные тесты. Захотели провести регрессию только по тестам с высоким приоритетом - запускаем только их. Если они будут тянуть за собой другие тесты - в отчете будет много лишнего. Например, мы запускаем 20 тестов, а в Jenkins или где-то еще 25 результатов. WTF???
Во фреймворке может быть общая процедура логина, и тесты могут ее переиспользовать. Но она не является тестом. Сам тест на логин может ее же вызывать, а потом делать какие-то дополнительные проверки, которые в других тестах повторять нет смысла, потому что они тестируют уже не логин. Ну, может быть, для логина проверять и не много, но потом где-нибудь такое объявится. А вы тесты целиком хотите затягивать в другие.

[Spock]

 

 

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

Это как раз основной недостаток такого подхода. Представьте что у Вас не 3 теста, а 10 или 100. При отказе первого, остальные 10 не выполнятся. Это по терминологии xUnit запах поведения: http://xunitpatterns...ratic Test.html

тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость

 

 

 

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

Почему бы не подчищать за собой после каждого теста? Можно реализовать независимые тесты и выполнять запуск параллельно. 

был бы и рад подчищать - но далеко не везде на уровне интеграционных тестов есть "подчистка". Например нет удаления пользователя - а только деактивация, есть отмена покупки но не её удаление

 

 

Кстати говоря, в Вашем примере, зачем вообще нужно 3 теста, если все необходимые проверки выполнятся в последнем?

Цитата

 

тест3, покупка:

создать юзера

залогинить юзера

сделать покупку

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

 

 

 

Ну, делать граф зависимостей тестов - это концептуально неверно.

это концептуально неверно только для юнит-тестов, а для интеграционных куча зависимостей всегда

Конечно удобно говорить про "независимость" тестов - а когда у тебя например сотни тестов, должен ли каждый тест создавать пользователя, добавлять в группы, регистрировать кредитку, класть деньги на кредитку и т.п. Вот тогда и приходится делать интеграционные тесты "зависимыми", чтобы один тест создал, другой залогинился, третий зарегистрировал кредитку и так далее

 

 

 

Захотели провести регрессию только по тестам с высоким приоритетом - запускаем только их. Если они будут тянуть за собой другие тесты - в отчете будет много лишнего. Например, мы запускаем 20 тестов, а в Jenkins или где-то еще 25 результатов. WTF???

гляну что там в Дженкинс получается. Но ведь всё равно даже когда запускаешь тест "только покупка" - он потянет за собой вызовы методов "регистрация" и "логин" всё равно, то есть как ни крутись, тест никак не "независимый", а только выглядит независимым в Дженкинсе

 

 

 

А вы тесты целиком хотите затягивать в другие. 

тут не затягивать - а делать последовательность. Например один тест регистрирует пользователя, другой тест делает покупки, третий генерирует отчёт. Может быть удобно если эти три теста пойдут один за другим и переиспользуют уже созданные данные

[bobylev]

тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость

Проблема решается небольшим набором Smoke-тестов на базовую функциональность и взаимодействие компонентов. Если хоть один из них не прошел, остальные тесты не запускаются.

[Spock]

 

 

Проблема решается небольшим набором Smoke-тестов на базовую функциональность и взаимодействие компонентов. Если хоть один из них не прошел, остальные тесты не запускаются.

Пример:

тест на пополнение кредитки не прошёл - значит можно не запускать покупки

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

 

следовательно:

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

[Vasiliy]

тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость

 
Не очень ясно. Не работает функционал логина, ок. Почему нельзя проверить исправления в модуле покупок?
 

Конечно удобно говорить про "независимость" тестов - а когда у тебя например сотни тестов, должен ли каждый тест создавать пользователя, добавлять в группы, регистрировать кредитку, класть деньги на кредитку и т.п. Вот тогда и приходится делать интеграционные тесты "зависимыми", чтобы один тест создал, другой залогинился, третий зарегистрировал кредитку и так далее

Не должен!
Хотите там создавать пользователя - создавайте, но не делайте из него тест.
На мой взгляд, для этого есть раздел предусловия - нужен такой-то пользователь.

[Spock]

 

тут имеется ввиду что смысла запускать все тесты на "покупку" нет смысла когда тест "логин" завалился. Вот один тест "логин" завалится а 100 тестов про покупку даже не будут запускаться и будут помечены как "пропущенные" - билд пройдёт очень быстро и сразу получим результаты. Тут так называемая "жёсткая" зависимость

 
Не очень ясно. Не работает функционал логина, ок. Почему нельзя проверить исправления в модуле покупок?

проверить конечно можно, тут вопрос только насколько тесты должны уметь "покупать без логина". Насколько реалистичны будут такие тесты? 

 

 

 

Не должен!
Хотите там создавать пользователя - создавайте, но не делайте из него тест.
На мой взгляд, для этого есть раздел предусловия - нужен такой-то пользователь.

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

 

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

[Vasiliy]

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

Да. А что вас в этом смущает?)

[baxatob]

Все предусловия должны быть созданы ДО запуска тестов.

1. Для каких-то тестов должен быть заранее приготовлен набор разных пользователей.

2. При этом создание пользователей должно быть предметом отдельных тестов.

1 и 2 никак не должны влять друг на друга.

[Spock]

 

Все предусловия должны быть созданы ДО запуска тестов.

1. Для каких-то тестов должен быть заранее приготовлен набор разных пользователей.

2. При этом создание пользователей должно быть предметом отдельных тестов.

1 и 2 никак не должны влять друг на друга.

"2. При этом создание пользователей должно быть предметом отдельных тестов." - а кто решает должно ли это быть тестом или нет?

 

например для теста "права админа" создаётся "админ"

и ещё для теста "создание админа" опять создаётся "админ"

 

получается что можно один раз создать "админа" - в тесте "создание админа", и не создавать админа 2 раза

[Vasiliy]

"2. При этом создание пользователей должно быть предметом отдельных тестов." - а кто решает должно ли это быть тестом или нет?
 
например для теста "права админа" создаётся "админ"

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

и ещё для теста "создание админа" опять создаётся "админ"

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

[Spock]

 

 

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

 

 

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

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

 

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

 

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

[Spock]

нашёл что TestNG позиционируется как тул, у которого есть "зависимость тестов от тестов", и этим он лучше для интеграционного тестирования

 

попробовал, оказывается что сам TestNG да, работает с зависимостями тестов от тестов, можно настраивать цепочки и передавать параметры, всё прекрасно, зависимости собираются, граф строится автоматом, тестНГ разбирается кого каким порядком запустить, запускается на Дженкинсе и всё такое

 

НО! в Intellij Idea плагине для TestNG существует поддержка только dependsOnMethod, а у TestNG есть ограничение что эта зависимость должна быть только внутри класса. Вообще нереально держать все методы в одном классе, в одном файле

 

получается единственный способ в TestNG сделать зависимости тестов от тестов - это использование dependsOnGroups, а это оказывается не поддерживается в Intellij Idea плагине для TestNG! 

баг уже заведён назад нашим человеком больше чем год назад, но до сих пор никакой реакции от JetBrains, им пофиг

 

Add a way to run a single TestNG test which has dependencies

https://youtrack.jet...sue/IDEA-141621

 

А без поддержки плагином зависимый тест не получается из IDE запустить нажав на "зелёную кнопку" - зависимости не собираются! ошибка "depends on nonexistent group". Получается если хочешь дебажить тест - надо запускать TestNG тест через командную строку и подключать Remote Debugger к тестам! o_O

 

вот в документации TestNG описание зависимостей тестов от тестов:

http://testng.org/do...pendent-methods