EB
#ios #xcuitest #swift #testrail #integration
В задаче интеграции отчетов тестов возник вопрос, который не так просто гуглится: в pytest есть скоуп сессии, когда фикстура в рамках подготовки теста может выполнить что-то один раз. В такой скоуп очень удобно поместить интеграцию с Testrail, например, и создать test execution через Testrail API.
НО,
Apple в XCUITest session обьект решил не завозить (или я не нашел в сорсах). Думаю пользоваться сетапом для методов, с проверкой, была ли инициализированна глобальная переменная test_execution_id, и если была то создать прогон. Это решение выглядит несколько костыльным, потому что задача на сессию выполняется один раз в первом сетапе тест-метода, а все последующие сетапы тест методов будут каждый раз проверять состояние инициализации переменной. Может быть натолкнете на более кошерные решения?
В задаче интеграции отчетов тестов возник вопрос, который не так просто гуглится: в pytest есть скоуп сессии, когда фикстура в рамках подготовки теста может выполнить что-то один раз. В такой скоуп очень удобно поместить интеграцию с Testrail, например, и создать test execution через Testrail API.
НО,
Apple в XCUITest session обьект решил не завозить (или я не нашел в сорсах). Думаю пользоваться сетапом для методов, с проверкой, была ли инициализированна глобальная переменная test_execution_id, и если была то создать прогон. Это решение выглядит несколько костыльным, потому что задача на сессию выполняется один раз в первом сетапе тест-метода, а все последующие сетапы тест методов будут каждый раз проверять состояние инициализации переменной. Может быть натолкнете на более кошерные решения?
#solution
Решение которое решил не делать, но которое идологически правильное:
Использовать протокол XCTest observation.
Решил не делать, потому что пришлось бы много кода перетаскивать из существующего сабкласса XCTestCase в Observer.
И логика teardown / setup была бы размазана на методы которые используются в XCTest и на Обзервер.
Что я сделал 👽:
Struct с парой полей, которые глобально заменили мне сессию, а сам код взаимодействия с shared state положил в test case setUp. Инициализириуется один раз, а дальше всегда скипается, как и хотелось.
Изначально этот подход казался плохим, но после изучения всего паршивого дизайна эпл фреймворков понял, что это будет наименьшим из зол
Решение которое решил не делать, но которое идологически правильное:
Использовать протокол XCTest observation.
Решил не делать, потому что пришлось бы много кода перетаскивать из существующего сабкласса XCTestCase в Observer.
И логика teardown / setup была бы размазана на методы которые используются в XCTest и на Обзервер.
Что я сделал 👽:
Struct с парой полей, которые глобально заменили мне сессию, а сам код взаимодействия с shared state положил в test case setUp. Инициализириуется один раз, а дальше всегда скипается, как и хотелось.
Изначально этот подход казался плохим, но после изучения всего паршивого дизайна эпл фреймворков понял, что это будет наименьшим из зол
