СС
ну оно же в 1 браузере один фиг
Size: a a a
2021 September 07
AT
да, но если один и тот же виджет используется на 2х разных платформах с разными стилями и логикой, возникает вопрос как это тестировать избегая множественных дубликатов
D
Ничего особенного в микрофронтендах нет https://youtu.be/ToPByQbTfzU
D
В монолитном фронтенде то же самое бывает)
AT
Смотрел. Но согласитесь, что подход нетипичный для, скажем так, монолитного фронта. Сплит тестов по разным уровням для каждого компонента
АТ
ну тогда же это не один и тот же виджет ))
D
Нетипичный потому что инструменты всего пару лет назад появились и некоторым людям интереснее пиарить селениды. А так типичная пирамида тестирования, только в контексте фронтенда
D
Поведение/код виджета один, просто свойства отличаются
DD
точно, отличная идея) попробую реализовать,
AT
Каждый виджет как отдельная аппа со своими unit, integration (api) и е2е тестами.
D
Ну вы же можете тестировать микрофронтенд по-старинке одними только е2е тестами на разных девайсах.
Микрофронтендная архитектура позволяет опуститься на пару уровней ниже, чтобы сдвинуть тестирование влево и получать фидбек от тестов раньше, чем в монолите, но это не обязательное требование к тестированию. Если у вас для этого не хватает бюджета или скиллов, то всегда можно откатиться к е2е тестам)
Микрофронтендная архитектура позволяет опуститься на пару уровней ниже, чтобы сдвинуть тестирование влево и получать фидбек от тестов раньше, чем в монолите, но это не обязательное требование к тестированию. Если у вас для этого не хватает бюджета или скиллов, то всегда можно откатиться к е2е тестам)
AT
Вот к этому я веду, ибо использование е2е как эталона и единственный подход в тестировании - довольно накладно по времени
D
Такая же история как с бэкенд микросервисами. Можно писать компонентные, контрактные, интеграционные тесты, а можно просто обмазаться е2е 😄
AT
классика
D
Ну пирамида реально требует в полтора-два раза больше ресурсов на поддержку, чем е2е. Так что часто у людей есть желание, но тупо нет возможностей. Для этого нужен чёткий коммитмент со стороны менеджмента
AT
Вот здесь в точку
С
Ребят, всем привет, может кто помочь?
Задача переписать тест в JDI на Selenide
Элемент на JDI выглядит вот так, по какой-то магической причине в Selenide у меня не получается создать листы элементов, если я просто получу массив через $$, то он находит элементы, но суть в том, что $ или $$ возвращает Selenide element, а мне нужен OutputFormatForm
При этом если указать не лист, а просто OutputFormatForm, то найдет
Задача переписать тест в JDI на Selenide
Элемент на JDI выглядит вот так, по какой-то магической причине в Selenide у меня не получается создать листы элементов, если я просто получу массив через $$, то он находит элементы, но суть в том, что $ или $$ возвращает Selenide element, а мне нужен OutputFormatForm
При этом если указать не лист, а просто OutputFormatForm, то найдет
OB
а что за тип такой OutputFormatForm?
С
Ну это наш собственный класс
OB
если java 8, можно через стримы:
ElementsCollection outputs = $$x("locator");
List<OutputFormatForm> outputList = outputs.stream().map(OutputFormatForm::new).collect(toList());
ElementsCollection outputs = $$x("locator");
List<OutputFormatForm> outputList = outputs.stream().map(OutputFormatForm::new).collect(toList());