AS
Я просто пытаюсь понять, какую реальную проблему мы решаем. Не воспринимайте в штыки. ;)
Size: a a a
2021 November 17
PO
Хм, например мы хотим, чтобы по дефолту у всех тестов было ожидание на 4 а 10 секунд, не было автоматических скриншотов и кастомная директория для загрузки файлов. Но при этом у нас несколько фикстур для тестов, как сейчас захендлить это посредством Selenide?
AS
Не знаю, что вы понимаете под словом "фикстура", но что вам мешает создать одну фикстуру с таймаутом в 10 секунд для всех тестов?
PO
Под фикстурой условный BaseTest, с методом BeforeAll/BeforeSuite. В джава множественного наследования нет, да и ситуаций когда тебе нужно разные фикстуры для разных тестов хватает.
PO
Но и да, это не проблема которую по другому не решить, но текущие решения не самые удобные
MS
а через интерфейсы не пробовали? В одном сделать BeforeAll с аллюром, в другом еще с чем-нибудь. И перечисляете то, что нужно. Только название разные должны быть у фикстур, конечно же.
AK
у junit есть BeforeAllCallback/BeforeEachCallback
PO
Не пробовал, но в таком случае ты должен кругом таскать этот интерфейс и не провтыкивать добавлять, + самом метод будет вызываться несколько раз и делать одно тоже, что так себе.
AS
@petro_ov Да, я бы тоже такое делал через мезанизм JUnit. Типа такого:
@ExtendedWith({UITestsFixture.class, PaymentsFixture.class})
public class InternationalPaymentTest {…}
AS
Да, при таком подходе есть риск, что в каком-то тесте ты можешь забыть прописать
Но можно сделать так, чтобы тесты валились, если ты забыл прописать.
UITestsFixture. Но можно сделать так, чтобы тесты валились, если ты забыл прописать.
AS
Но по крайней мере я понял, что вы хотите сделать - чтобы один раз положить файлик selenide.properties в classpath и нигде ничего больше не прописывать. Спасибо. Вроде разумно.
AS
@petro_ov Но тогда ещё пара вопросов:
1. Если там глобальные настройки длы всех тестов типа таймаута, зачем подкладывать этот файл руками на дженкинс? Почему бы его сразу не закоммитить в проект?
2. Что, если в каком-то тесте тебе не подойдёт содержимое этого файла? Отменить его загрузку ведь уже не получится.
1. Если там глобальные настройки длы всех тестов типа таймаута, зачем подкладывать этот файл руками на дженкинс? Почему бы его сразу не закоммитить в проект?
2. Что, если в каком-то тесте тебе не подойдёт содержимое этого файла? Отменить его загрузку ведь уже не получится.
PO
Дефолтный файл и так лежит в репнике, отдельный лишь используются в специфических тестах. Просто заменять один файл легче, мб имхо, чем пробрасывать с пол дюжины пропертей в билд. (Файлы хранятся под разными id и когда нужно, их явно передаем в настройке джобы и он перезаписывает дефолтный, если кастомных параметров мало то -D… и погнали)
PO
Я выбрал вариант лисенера, подключенного через SPI, но все же ощущение, что это все костыли, поверх селенида(
AS
Да не, я пока не вижу ничего плохого.
Попробуй сформулировать минусу этого "костыля". Что может сломаться? Какая проблема с ним часто случается?
Попробуй сформулировать минусу этого "костыля". Что может сломаться? Какая проблема с ним часто случается?
PO
Это зависимость на внешнюю библиотеку, тестнг/junit/etc. Надо добавлять каждому отдельно, придумывать свои реализации.
PO
Хотя это просто конфигуряция самого селенида
AS
Да, верно: надо добавлять каждому отдельно. Но я предполагаю, что по-любому придется каждому самому добавлять что-то подобное, потому что кроме селенида, в проекте всегда будут какие-то ещё настройки. Это неизбежно.
AK
показли бы пример пропертей, без кредов офк)
AK
просто мне кажется, если вы запускаете на машине только определенные тесты, то проще наверно просто прокинуть переменные окружения