хм... может быть. Но зачем скролить страницу для получения списка?О_о У вас элементы динамически подгружаются/выгружаются из DOMa?

Привет. Подскажите, пожалуйста, как сделать (Selenium only):
Есть список товаров отображаются плиткой (вариант отображения менять нельзя), всего их 14, отображаются по 3 в ряд,  2 ряда в окне, чтобы отобразить остальные нужно скроллить страницу. Мне нужно каждый товар добавить в корзину. Как поступить?) Я пробую через find_elements искать часть товаров и добавлять их, потом скроллить страницу -  искать и добавлять следующие товары и т.д. Но во-первых не очень получается (хотя с этим я разберусь), а во-вторых это не круто (и что делать, если кол-во товаров изменится?). Есть решение получше?

что конкретно вы тестите в этом кейсе?
пишет команда разработчиков юнит ui тесты для фронта?
есть ли тесты на бэк?

что конкретно вы тестите в этом кейсе?
пишет команда разработчиков юнит ui тесты для фронта?
есть ли тесты на бэк?

в этом конкретном тесте проверяю, что у всех товаров есть цена и она верна.
пишет команда разработчиков юнит ui тесты для фронта? - нет: Я единственный тестировщик, мне сказали "Нужны автотесты на магазин, проверять нужно вот это, это и это" и я стал писать на него автотесты)
есть ли тесты на бэк? - вероятно нет

а вы не хотите получить массив элементов не товаров, а их ценников, прочитать с него текст (getText(), вроде, работает для массивов и выдает массив), а потом сравнить с expected массивом цен?

или в тесте проверяется еще и правильный подсчет суммы при добавлении товаров?

вариант ,не думал об этом. Но тогда нужно иметь массив   список с эталонными ценами, такой же длины и чтобы все цены стояли на своих местах, и были наисаны без ошибок. Мне кажется намного проще сравнивать суммы в поле Итого. Реально не понимаю зачем усложнять (врядли так совпадёт, что один товар будет на X дешевле, а другой на X дороже). Хотел ли я проверять правильно ли подсчитывается сумма уже не помню (я писал тест-кейсы пару месяцев назад), но скорее всего

Если такой тест упадет - у вас будет большая проблема разобраться что пошло не так - какая цена пришла не правильной

в этом конкретном тесте проверяю, что у всех товаров есть цена и она верна.
пишет команда разработчиков юнит ui тесты для фронта? - нет: Я единственный тестировщик, мне сказали "Нужны автотесты на магазин, проверять нужно вот это, это и это" и я стал писать на него автотесты)
есть ли тесты на бэк? - вероятно нет

Интересные вопросы. Какие действия предполагаются при вариантах ответов:
-2.Да, 3.Да
-2.Нет, 3. Нет.

вариант ,не думал об этом. Но тогда нужно иметь массив   список с эталонными ценами, такой же длины и чтобы все цены стояли на своих местах, и были наисаны без ошибок. Мне кажется намного проще сравнивать суммы в поле Итого. Реально не понимаю зачем усложнять (врядли так совпадёт, что один товар будет на X дешевле, а другой на X дороже). Хотел ли я проверять правильно ли подсчитывается сумма уже не помню (я писал тест-кейсы пару месяцев назад), но скорее всего

например, можно протестить бэк, что он отдает фронту правильные цены )
можно фронт покрыть компонентными тестами, проверить рендеринг компонентов в зависимости от прилетевших данных из бэка (моки моки моки)
на Ui оставить парочку функциональных тестов, которые проверяют, что в связке фронт+бэк все работает

а вы как-то подготавливаете тестовые данные? или тестируете сразу продакшен и поэтому не знаете, какие именно товары в данный момент есть на странице? Прошу прощения за любопытство, просто интересно, че как у других устроено