AK
И вообще у человека заработало, нашли до чего докопаться
Size: a a a
2019 November 13
M
Предугадывание ошибки
можете предугадать где у меня будет ошибка?
AB
Andrei Solntsev
Ну, не стало, а было. Метод Selenide.close() внутри дёргает webdriver.quit() - это факап, конечно, но он был сделан в самом начале, когда мы были молоды и не читали javadoc.
а чего б не поменять? можно, конечно, просто добавить метод closeWindow(), а можно и поведение метода close() изменить. потому что 1) все равно обычно никто не закрывает браузер, он закрывается сам, 2) редко кому надо закрывать браузер с несколькими окнами, а когда закрывается последнее окно — закрывается и весь браузер, семантика совпадает, 3) если совсем край — можно сделать конфигурационный параметр, который переключает поведение, кому надо — переключит параметр
AS
Да пожалуй верно, почему б не поменять.
A
всем привет
юзаю тестнг: при падении afterMethod сам тест логично маркается в отчете как Passed
могу ли в как-то принудительно маркать тест фейлд? пробовал через контекст ставить тест в пасд, но это немодифицируемая коллекции
юзаю тестнг: при падении afterMethod сам тест логично маркается в отчете как Passed
могу ли в как-то принудительно маркать тест фейлд? пробовал через контекст ставить тест в пасд, но это немодифицируемая коллекции
IR
Ребят подскажите как экстрактить данные из тела ответа в rest-assured?
MK
всем привет
юзаю тестнг: при падении afterMethod сам тест логично маркается в отчете как Passed
могу ли в как-то принудительно маркать тест фейлд? пробовал через контекст ставить тест в пасд, но это немодифицируемая коллекции
юзаю тестнг: при падении afterMethod сам тест логично маркается в отчете как Passed
могу ли в как-то принудительно маркать тест фейлд? пробовал через контекст ставить тест в пасд, но это немодифицируемая коллекции
Чото странно. Тест тоже должен упасть
MK
Ребят подскажите как экстрактить данные из тела ответа в rest-assured?
Руками и кодом
M
Ребят подскажите как экстрактить данные из тела ответа в rest-assured?
@zewcha любит его, думаю подскажет
ZE
P
Ребят подскажите как экстрактить данные из тела ответа в rest-assured?
then.extract.jsonPath.getString типа такого что-то
Y
Ребят подскажите как экстрактить данные из тела ответа в rest-assured?
Если приходит JSON, то com.google.gson.Gson в помощь.
Сперва создаете ожидаемую респонсом модель SomeModel, потом
SomeModel someModel = new Gson().fromJson(responseFromRestAssuredAsString, SomeModel.class);
Сперва создаете ожидаемую респонсом модель SomeModel, потом
SomeModel someModel = new Gson().fromJson(responseFromRestAssuredAsString, SomeModel.class);
IR
Yury
Если приходит JSON, то com.google.gson.Gson в помощь.
Сперва создаете ожидаемую респонсом модель SomeModel, потом
SomeModel someModel = new Gson().fromJson(responseFromRestAssuredAsString, SomeModel.class);
Сперва создаете ожидаемую респонсом модель SomeModel, потом
SomeModel someModel = new Gson().fromJson(responseFromRestAssuredAsString, SomeModel.class);
Спасибо Вам!
D
Чото странно. Тест тоже должен упасть
Нет, сам тест не падает при таком раскладе (по крайней мере у меня) и это логично, афтер - уже не часть теста
EB
#question #test_design #manual #automation #bus_factor
Чат, есть вопрос по тест-дизайну,
Представьте что есть тестировщики и они педалят тесты и пишут их в тестплан. Все проверки так или иначе ориентированы на грубо говоря какой-то network_id. Каждый нетворк -- это набор выбранных в него "фичей", то есть не факт, что такой нетворк будет создан в реальности. Тестировщики решили насобирать таких нетворков с разными сочетаниями,
Тестировщики эти работают по черному ящику,
Автоматизатор решает эти кейсы автоматизировать, но получает много вопросов от разработчика "ты проверяешь это в другом кейсе, а можно в одном", то есть здесь получается, что тест дизайн от программиста включает знание системы и того, откуда растут ноги у "разных" нетворков. Ручные тестировщики при этом пилят, особо в код не смотря.
Это была ситуация, а теперь вопросы:
1) не вносит ли автоматизатор бас фактор. создавая тесты, в дизайне которых ручные тестировщики не участвуют
2) не лучше ли научить тестировщиков руками тест-дизайнить так, чтобы вопросов от разработчика таких не было (другими словами, тестировщики должны используя белый ящик и классы эквивалентности нарезать тест-кейсов минимально допустимое количество)
3) Не кажется ли вам расхождение автотестов от существующих тест планов бомбой замедленного действия?Даже если они time efficient
Чат, есть вопрос по тест-дизайну,
Представьте что есть тестировщики и они педалят тесты и пишут их в тестплан. Все проверки так или иначе ориентированы на грубо говоря какой-то network_id. Каждый нетворк -- это набор выбранных в него "фичей", то есть не факт, что такой нетворк будет создан в реальности. Тестировщики решили насобирать таких нетворков с разными сочетаниями,
Тестировщики эти работают по черному ящику,
Автоматизатор решает эти кейсы автоматизировать, но получает много вопросов от разработчика "ты проверяешь это в другом кейсе, а можно в одном", то есть здесь получается, что тест дизайн от программиста включает знание системы и того, откуда растут ноги у "разных" нетворков. Ручные тестировщики при этом пилят, особо в код не смотря.
Это была ситуация, а теперь вопросы:
1) не вносит ли автоматизатор бас фактор. создавая тесты, в дизайне которых ручные тестировщики не участвуют
2) не лучше ли научить тестировщиков руками тест-дизайнить так, чтобы вопросов от разработчика таких не было (другими словами, тестировщики должны используя белый ящик и классы эквивалентности нарезать тест-кейсов минимально допустимое количество)
3) Не кажется ли вам расхождение автотестов от существующих тест планов бомбой замедленного действия?Даже если они time efficient
ES
Разработчики должны участвовать в ревью тест кейсов желательно
MK
Eugene Sevostianov
Разработчики должны участвовать в ревью тест кейсов желательно
Нет. Наоборот
MK
Снизу вверх все идёт
ES
Ну если автоматизатору разработчик говорит что тест кейсы не совсем валидны и верны то явно не наоборот ))
MK
Eugene Sevostianov
Ну если автоматизатору разработчик говорит что тест кейсы не совсем валидны и верны то явно не наоборот ))
Значит ассенизатор тупой и точка. Не умеет в тест дизайн