Спасибо, рад что понравилось! Да, как правило тестируется связка классов, обслуживающих одну view. Взаимодействие VIPER модулей, если физически это разные экраны, проверяем через UI тесты.
Но если надо протестировать сложный экран, состоящий из нескольких VIPER модулей (например, в экран встроены сложные переиспользуемые вьюхи, которые сами уже являются VIPER модулями), то получится, что модульный тест будет проверять связку VIPER модулей. Но и саму эту переиспользуемую вьюху имеет смысл покрыть отдельным комплектом модульных тестов.
Тоже смотрим в сторону распараллеливания запуска, но на симуляторах через emcee. Тесты пишем нативные (XCUITest). От аппиума отказались, считаем что разработчики сами должны писать тесты на свой код, а им удобнее работать с нативными инструментами.
Да и вообще больше сейчас фокусируемся на модульных тестах, UI тесты в основном используем для проверки наиболее критичного функционала и того, что нельзя проверить с помощью UI тестов.
По поводу времени: Модульные прогоняются около минут 20 на CI. Их количество затрудняюсь ответить, потому что мы пишем на Quick, а там не совсем понятно, что считать одним тестом. UI тестов около 380шт, их прогон занимает около 4 часов. Как-то точно замерить выигрыш по времени довольно сложно, но количество добавляемых UI тестов стало постепенно уменьшаться, т.к. кейсы, которые мы раньше тестировали медленными UI тестами, мы стали тестировать через модульные и unit тесты. Грубо говоря, время прогонов и время на поддержку UI тестов стало рости медленнее.
По поводу Android: На андройде тесты тоже пишут разработчики. Они пишут UI тесты на критические кейсы и unit тесты на бизнес логику.
По поводу QA: У QA из своей команды можно запросить помощь в написании тестовых сценариев, но какие проверку будут выполняться на уровне модульных тестов, а какие на уровне UI тестов должен решать сам разработчик.
На данный момент мы не используем DI, пока все на фабриках. В тестах создается своя фабрика, которая собирает модуль для тестирования с замоканными зависимостями. Я думаю для DI можно так же создавать отдельный DI контейнер, например.
Привет! Для моков запросов в UI тестах мы используем библиотеку SBTUITestTunnel и свои простые обертки над ней. Обертки нужны чтобы сразу передавать url который надо замокать и название json файла с респонсом. В целом для обработки всех базовых кейсов нас устраивает. А в планах еще есть статься о том, как готовить UI тесты, чтобы не было мучительно больно.
И правда, спасибо за поправку!
Спасибо, рад что понравилось!
Да, как правило тестируется связка классов, обслуживающих одну view. Взаимодействие VIPER модулей, если физически это разные экраны, проверяем через UI тесты.
Но если надо протестировать сложный экран, состоящий из нескольких VIPER модулей (например, в экран встроены сложные переиспользуемые вьюхи, которые сами уже являются VIPER модулями), то получится, что модульный тест будет проверять связку VIPER модулей. Но и саму эту переиспользуемую вьюху имеет смысл покрыть отдельным комплектом модульных тестов.
Звучит интересно!
Тоже смотрим в сторону распараллеливания запуска, но на симуляторах через emcee.
Тесты пишем нативные (XCUITest). От аппиума отказались, считаем что разработчики сами должны писать тесты на свой код, а им удобнее работать с нативными инструментами.
Да и вообще больше сейчас фокусируемся на модульных тестах, UI тесты в основном используем для проверки наиболее критичного функционала и того, что нельзя проверить с помощью UI тестов.
Спасибо за вопрос!
По поводу времени:
Модульные прогоняются около минут 20 на CI. Их количество затрудняюсь ответить, потому что мы пишем на Quick, а там не совсем понятно, что считать одним тестом.
UI тестов около 380шт, их прогон занимает около 4 часов. Как-то точно замерить выигрыш по времени довольно сложно, но количество добавляемых UI тестов стало постепенно уменьшаться, т.к. кейсы, которые мы раньше тестировали медленными UI тестами, мы стали тестировать через модульные и unit тесты. Грубо говоря, время прогонов и время на поддержку UI тестов стало рости медленнее.
По поводу Android:
На андройде тесты тоже пишут разработчики. Они пишут UI тесты на критические кейсы и unit тесты на бизнес логику.
По поводу QA:
У QA из своей команды можно запросить помощь в написании тестовых сценариев, но какие проверку будут выполняться на уровне модульных тестов, а какие на уровне UI тестов должен решать сам разработчик.
На данный момент мы не используем DI, пока все на фабриках.
В тестах создается своя фабрика, которая собирает модуль для тестирования с замоканными зависимостями.
Я думаю для DI можно так же создавать отдельный DI контейнер, например.
Привет!
Для моков запросов в UI тестах мы используем библиотеку SBTUITestTunnel и свои простые обертки над ней. Обертки нужны чтобы сразу передавать url который надо замокать и название json файла с респонсом. В целом для обработки всех базовых кейсов нас устраивает.
А в планах еще есть статься о том, как готовить UI тесты, чтобы не было мучительно больно.