Нет, даже не при успешном выполнении кейса пост запрос может создать данные, но дата провайдер отправляет в тест информацию, какие таблицы нужно очистить, и вот метод который отвечает ща очистку я хочу переместить в метод _after, таким образом таблицы будут очищатся при любом результате теста

Но вопрос был не в том какой метод использовать, а в том как передать в него данные из дата провайдера возможно ли что бы дата провайдер отдавал данные и в функции
_before
tryToTest
_after

Сейчас дата провайдер отдает данные только в функцию tryToTest

Здравствуйте!
Исходные данные:
- Appium+PyTest;
- Android-приложение;
- список элементов-контейнеров (div'ы, LinearLayout'ы)(содержат в себе нужные данные, которые нужно проверять и по которым нужно выбирать необходимый элемент и тапнуть/кликнуть);
- есть запрос на API, который возвращает этот список в JSON-формате и по которому строится этот UI (можно использовать в качестве тестовых/исходных данных);
- на экране (5'') полностью могут отображаться только 3 элемента из этого списка;
- на экране элементы списка могут отображаться не полностью;

Проблема1: список может быть достаточно большим, он может меняться по положению звёзд на небе (не предсказать). Но есть запрос на API, который возвращает этот список в JSON-формате и по которому строится этот UI (можно использовать в качестве тестовых/исходных данных).
Проблема2: на экране элементы списка могут отображаться не полностью, соответственно, нужна какая-то логика, которая будет это учитывать и не пытаться найти элемент-контейнер, который отображается не полностью и вложенные элементы, которого, соответственно, будет не достать в данный момент.

Что пробовал:
- без каких-то специальных средств, с помощью алгоритмов, driver.scroll, find_elements_by_xpath, find_elements_by_id и такой-то матери... получается не очень надёжно...
- с помощью UiAutomator-UiSelector-UiScrollable, уже чуть получше, но всё равно, есть свои нюансы: нужно задавать алгоритм перехода от одного элемента к другому, т.к. иначе он начнёт листать список не в ту сторону... иногда это ничего, иногда, для таких элементов UI как BottomSheetDialog - это очень критично (просто тупо закрывает список, пролистывая не в ту сторону). Вообще, странно, кстати, почему изначально этот селектор пытается скроллить/свайпить вверх (в начало списка), а не наоборот?... И можно ли как-то задать ему направление более конкретное? Типа: up/down для вертикального scrollable-элемента?
- увидел driver.execute_script, обрадовался, подумал: "ну всё, вот оно решение!", но не тут-то было! Оказывается:
https://github.com/appium/ruby_lib/issues/867
https://github.com/appium/appium/issues/9771
и ещё наверняка есть тикеты с жалобами и мольбами вернуть/запилить методы mobile: для Android.
- есть ещё Espresso'вский Data Matcher (https://appiumpro.com/editions/95-the-android-data-matcher-locator-strategy), который вроде бы тоже хорошо и просто решает данную проблему, но я так понял, что придётся поперелопатить половину локаторов/селекторов в PageObject'ах и плюс ещё неизвестно где будут грабли при переходе на другой драйвер... в общем не хотелось бы конечно...
Поправьте, пожалуйста, если я где-то не прав. Ну и очень буду признателен за годный совет как лучше всего решить эту задачу/проблему.

Как закрыть соединение на 27 сторе обьевлено

пощупай опцию --forceExit, может поможет)

костыли - это наше все 🙂 так что все норм)

Mime (https://www.npmjs.com/package/mime) version 2.0.0 onwards provides a force=true flag to allow multiple calls to .define() for the same mime type, which in turn stops the error from being thrown.

Fix as follows:

/**
 * Define "form" mime type.
 */

mime.define({
  'application/x-www-form-urlencoded': ['form', 'urlencoded', 'form-data']
}, true); // <--- add 'force=true' here