Кажется натыкалась на такую проблему, когда компоненты с одной страницы повторяются (тут уже точно что-то другое чем POM) , создала отдельный класс, к примеру FileDownloadManager, который управляет всеми действиями связанный с этим элементом, это можно применить к EOM который вы описали?
Ага, если пообщаетесь с фронтами они покажут как они структуру такую делают с каждым элементом и как наполняют страницу)
Добавить комментами внутри блока кода?
Можно и так
Да, это прям жиза, а что вы имеете ввиду Assertation в одну строку?
Меня тут скорей смущают куча параметров, но мб это в качестве примеров тут)
Разве BDD это не Given-When-Then? Тоже долго думала куда лучше отнести к TDD or BDD?
Неее, это нотация Gherkin, являющейся самой популярной сейчас для bdd. И многие теперь считают что нотация и есть сам принцип. Но это не единственное условие, его может и не быть, и он может быть представлен обычным тест-кейсом(ну это если упрощенно, можно еще про это тут почитать https://www.uml2.ru/partners/5004/)
500 элементов это будет пока и легко разбираться если сам сидишь и кодишь + явно будут конфликты и придется их решать. Тут хорошо сказали про практику EOM. Создаем отдельный интерфейс - к примеру попап который есть к примеру на каждой странице и описываем его элементы и можно даже их действия над ними. И в принципе все, любое изменение сразу понятно куда идти и что править. А потом для тестов можно просто собрать нужные нам элементы в страничку.
А почему не сразу веб-элементы записывать чтобы было к примеру danger_button.click(), а не селекторы?(и да добавьте тогда идентификатор в пример, а то одно локаторы)
Немного непонятно про расширение селекторов, почему не используются $(byText()), $(withText()), $(byTitle()) и прочие?
x-path - как говорится, просто не умеете их готовить) Есть плагины в chrome которые могут выдать достаточно приятный и короткий селектор, плюс сразу можно использовать поиск по тексту(под капотом селенида так и работает)
Плюс решение коллекции, совсем не решает проблему поиска элемента по индексу, так же с добавлением элемента в эту коллекцию тест начнет падать, поскольку его индекс изменился(ну или нет). Как вариант доп. поиск внутри коллекции, тот же текст, ну или класс.
Assertation в одну строку выглядит не очень, особенно если не включены Soft Assert, иначе всегда будет падать первое исключение(Правда есть минус - включается на все тесты сразу)
Про LocalStorage - тут у вас непонятно зачем и почему, есть возможность получить и скинуть токен, но для чего и почему не скинуть весь сразу?)
Состав кейса с его расшифровкой - не оч удобно читать, лучше б в одном порядке.
Не TDD, а все ж BDD - вы описываете поведение пользователя кликами на кнопки и прохождение сценария, TDD немного про другое https://habr.com/en/post/459620/.
Все ж переименуйте обратно Флоки во Flacky, все ж устоявшийся уже термин - а то Рагнар прибежит)
Кхм, а отключение js в браузере не слетает когда открывается чистый конфиг от вебдрайвера?
И просто ради интереса $$(DANGER_BTN) имеет локатор как - "danger-btn"?)
Ага, если пообщаетесь с фронтами они покажут как они структуру такую делают с каждым элементом и как наполняют страницу)
Можно и так
Меня тут скорей смущают куча параметров, но мб это в качестве примеров тут)
Неее, это нотация Gherkin, являющейся самой популярной сейчас для bdd. И многие теперь считают что нотация и есть сам принцип. Но это не единственное условие, его может и не быть, и он может быть представлен обычным тест-кейсом(ну это если упрощенно, можно еще про это тут почитать https://www.uml2.ru/partners/5004/)
Хм, интересно, поспрашиваю:
500 элементов это будет пока и легко разбираться если сам сидишь и кодишь + явно будут конфликты и придется их решать. Тут хорошо сказали про практику EOM. Создаем отдельный интерфейс - к примеру попап который есть к примеру на каждой странице и описываем его элементы и можно даже их действия над ними. И в принципе все, любое изменение сразу понятно куда идти и что править. А потом для тестов можно просто собрать нужные нам элементы в страничку.
А почему не сразу веб-элементы записывать чтобы было к примеру danger_button.click(), а не селекторы?(и да добавьте тогда идентификатор в пример, а то одно локаторы)
Немного непонятно про расширение селекторов, почему не используются $(byText()), $(withText()), $(byTitle()) и прочие?
x-path - как говорится, просто не умеете их готовить) Есть плагины в chrome которые могут выдать достаточно приятный и короткий селектор, плюс сразу можно использовать поиск по тексту(под капотом селенида так и работает)
Плюс решение коллекции, совсем не решает проблему поиска элемента по индексу, так же с добавлением элемента в эту коллекцию тест начнет падать, поскольку его индекс изменился(ну или нет). Как вариант доп. поиск внутри коллекции, тот же текст, ну или класс.
Assertation в одну строку выглядит не очень, особенно если не включены Soft Assert, иначе всегда будет падать первое исключение(Правда есть минус - включается на все тесты сразу)
Про LocalStorage - тут у вас непонятно зачем и почему, есть возможность получить и скинуть токен, но для чего и почему не скинуть весь сразу?)
Состав кейса с его расшифровкой - не оч удобно читать, лучше б в одном порядке.
Не TDD, а все ж BDD - вы описываете поведение пользователя кликами на кнопки и прохождение сценария, TDD немного про другое https://habr.com/en/post/459620/.
Все ж переименуйте обратно Флоки во Flacky, все ж устоявшийся уже термин - а то Рагнар прибежит)
Кхм, а отключение js в браузере не слетает когда открывается чистый конфиг от вебдрайвера?
И просто ради интереса $$(DANGER_BTN) имеет локатор как - "danger-btn"?)