EK
селениум живет уже сто лет и не добавить такой базис как то дико
Size: a a a
2019 November 12
MA
ниче странного, очень не часто требуется открывать еще одно окно или вкладку
EK
и тут тоже соглашусь
EK
впервые понадобилось
MA
Ну, ок. Означает не всегда, но часто ведёт к срезанию углов. И в другом порядке тесты перестают работать.
ну если для вас тесты - чудо и магия, то наверное да
MB
Вообще не понял к чему тут это, но ладно.
MA
> И в другом порядке тесты перестают работать.
Как могут независимые тесты пройти по-разному, если их переставить местами?
Как могут независимые тесты пройти по-разному, если их переставить местами?
MB
Это если они реально независимые. А если кто-то начинает срезать углы и первый тест создаст сущность, второй изменит, а третий удалит, то все три в нужном порядке отработают и ошибка и связность не будет видна. А если их поменять местами, то ошибка в тестах сразу вылезет в полный рост. Поэтому я и написал про «срезание углов». Подход с управлением порядка исполнения способствует появлению такого рода ошибок.
MZ
тогда у тебя зависимые тесты-то
MB
Не, у меня же их вообще нет. Это магия.
V
Люди добрые, помогите с тривиальной задачей:
Прокси для домохозяек. Для селенида нужно пройти авторизацию в прокси.
Configuration.proxyHost = "proxy.chick-chirik.com";
Configuration.proxyPort = 8080
А как приличные люди вводят логин и пароль?
Попробовал
System.setProperty("wdm.proxyUser", "логин");
System.setProperty("wdm.proxyPass", "пароль");
, не получилось. Сборка совсем зависла.
Прокси для домохозяек. Для селенида нужно пройти авторизацию в прокси.
Configuration.proxyHost = "proxy.chick-chirik.com";
Configuration.proxyPort = 8080
А как приличные люди вводят логин и пароль?
Попробовал
System.setProperty("wdm.proxyUser", "логин");
System.setProperty("wdm.proxyPass", "пароль");
, не получилось. Сборка совсем зависла.
AS
Андрей Солнцев не рекомендует параметризацию. 😎
Точнее не в юнит-тестах.
Точнее не в юнит-тестах.
Как раз наоборот, в юнит-тестах можно, а вот в интеграционных не советую.
AS
Но не нужно воспринимать всё как догму. Это всего лишь мнение одного человека.
Параметризация хорошо помогает соблюсти DRY и SRP, когда это нужно.
Параметризация хорошо помогает соблюсти DRY и SRP, когда это нужно.
Абсолютно верно, я и сам призываю не верить на слово, а слушать аргументы и думать своей головой.
Вот ты слушал аргументы?
Я пока не вижу, как DRY и SRP к этому вопросу вообще относятся.
Вот ты слушал аргументы?
Я пока не вижу, как DRY и SRP к этому вопросу вообще относятся.
V
Andrei Solntsev
Как раз наоборот, в юнит-тестах можно, а вот в интеграционных не советую.
Ешки матрёшки сам Андрей Солнцев в этом чате, а я то думаю что сегодня в Таллине безоблачно :)
MB
Andrei Solntsev
Как раз наоборот, в юнит-тестах можно, а вот в интеграционных не советую.
Двойное ж отрицание, Андрей 😁
AS
крутой аргумент - "если можно задавать порядок тестов - это плохо") а если его использовать не для и зависимости в тестах, а для приоритезации например, чтобы выдвинуть нужный функционал на первые места?
Да, совершенно верно, если порядок не для зависимости, то ничего плохого в этом нет.
(правда, как ты можешь быть уверен, что зависимость не возникнет - случайно или намеренно? Вот если хотя бы по ночам запускать их в случайном порядке, тогда да. А вы так делаете?)
(правда, как ты можешь быть уверен, что зависимость не возникнет - случайно или намеренно? Вот если хотя бы по ночам запускать их в случайном порядке, тогда да. А вы так делаете?)
MK
Andrei Solntsev
Как раз наоборот, в юнит-тестах можно, а вот в интеграционных не советую.
А можно пояснит в трёх словах что не так с ддт тестами? Если речь про параметризацию это ддт
AS
А можно пояснит в трёх словах что не так с ддт тестами? Если речь про параметризацию это ддт
Ну блин, вот же в видео всё объяснено: https://www.youtube.com/watch?v=U6z2dK7MwmI
MB
Andrei Solntsev
Абсолютно верно, я и сам призываю не верить на слово, а слушать аргументы и думать своей головой.
Вот ты слушал аргументы?
Я пока не вижу, как DRY и SRP к этому вопросу вообще относятся.
Вот ты слушал аргументы?
Я пока не вижу, как DRY и SRP к этому вопросу вообще относятся.
Очевидно, что слушал. Раз сам же повторно тут выложил ссылку на тот доклад. DRY - не повторять код, параметризация как раз этому весьма способствует. SRP - single responsibility principle, тут менее очевидно, но суть примерно схожая. Зачем несколько классов писать с одинаковым кодом, отличающимся входными данными.
MA
Andrei Solntsev
Да, совершенно верно, если порядок не для зависимости, то ничего плохого в этом нет.
(правда, как ты можешь быть уверен, что зависимость не возникнет - случайно или намеренно? Вот если хотя бы по ночам запускать их в случайном порядке, тогда да. А вы так делаете?)
(правда, как ты можешь быть уверен, что зависимость не возникнет - случайно или намеренно? Вот если хотя бы по ночам запускать их в случайном порядке, тогда да. А вы так делаете?)
Не делаю, ведь тесты не появились сразу пачкой. Они пришли по одному и в разные места. То есть процесс формирования сьюта он был практически рандомный и продолжает им оставаться. Гонять по ночам тесты в разных вариациях имеет смысл только тогда, когдв вы имеете практически 100%ное покрытие.