Комментарии 14
Спасибо за статью!
Можешь рассказать, как вы подменяете ответы от сервера в UI тестах?
Привет!
Для моков запросов в UI тестах мы используем библиотеку SBTUITestTunnel и свои простые обертки над ней. Обертки нужны чтобы сразу передавать url который надо замокать и название json файла с респонсом. В целом для обработки всех базовых кейсов нас устраивает.
А в планах еще есть статься о том, как готовить UI тесты, чтобы не было мучительно больно.
Как DI основного приложение пересекается с тестами? В тестах создаете зависимости заново? Пример указывает на это.
module = FakeFactory().makeModule()
Расскажите сколько тестов и как долго бегут. Сколько удалось сэкономить...
Если бы ваше приложение есть на Андроид - там тоже пишут девелоперы?
Как вовлечены обычные тестировщики? Кто проверяет какие тесты пишут дев?
спасибо
Спасибо за вопрос!
По поводу времени:
Модульные прогоняются около минут 20 на CI. Их количество затрудняюсь ответить, потому что мы пишем на Quick, а там не совсем понятно, что считать одним тестом.
UI тестов около 380шт, их прогон занимает около 4 часов. Как-то точно замерить выигрыш по времени довольно сложно, но количество добавляемых UI тестов стало постепенно уменьшаться, т.к. кейсы, которые мы раньше тестировали медленными UI тестами, мы стали тестировать через модульные и unit тесты. Грубо говоря, время прогонов и время на поддержку UI тестов стало рости медленнее.
По поводу Android:
На андройде тесты тоже пишут разработчики. Они пишут UI тесты на критические кейсы и unit тесты на бизнес логику.
По поводу QA:
У QA из своей команды можно запросить помощь в написании тестовых сценариев, но какие проверку будут выполняться на уровне модульных тестов, а какие на уровне UI тестов должен решать сам разработчик.
Как то сложно... Все сами пишут. Тестеры не очень управляют тестами.
Видимо эти 4 часа и решают.
Мы пошли иным путем. 750 UI тестов для каждой платформы. Время прогона 1500 тестов (обе платформы iOS + Android) на 24тел около 2.5 часов. Видео всех тестов, Аллур отчет, ошибки только с описанием (никаких NPE, только то то и то то не появилось или неправильно), совместили с ТестРейлом. Как результат Тестеры сами все запускают, смотрят, говорят что добавить. Девелоперы (как мобайл так и сервер) тоже уже научились запускать (разбили сьюты по фичам).
За первый час уже практически вся регрессия ловится.
А вы на чем UI тесты пишете? У нас Аппиум + Java.
Звучит интересно!
Тоже смотрим в сторону распараллеливания запуска, но на симуляторах через emcee.
Тесты пишем нативные (XCUITest). От аппиума отказались, считаем что разработчики сами должны писать тесты на свой код, а им удобнее работать с нативными инструментами.
Да и вообще больше сейчас фокусируемся на модульных тестах, UI тесты в основном используем для проверки наиболее критичного функционала и того, что нельзя проверить с помощью UI тестов.
Отличная статья!
Подскажите, в рамках одного модульного теста всегда тестируется набор классов, обслуживающий одну view? Или также пишете модульные тесты, покрывающие несколько экранов?
Спасибо, рад что понравилось!
Да, как правило тестируется связка классов, обслуживающих одну view. Взаимодействие VIPER модулей, если физически это разные экраны, проверяем через UI тесты.
Но если надо протестировать сложный экран, состоящий из нескольких VIPER модулей (например, в экран встроены сложные переиспользуемые вьюхи, которые сами уже являются VIPER модулями), то получится, что модульный тест будет проверять связку VIPER модулей. Но и саму эту переиспользуемую вьюху имеет смысл покрыть отдельным комплектом модульных тестов.
Кажется, в примере копирования логики для проверки значений, стоит поправить: XCTAssertEqual(result, "(stringA)(stringB)") // неправильно, на " \(stringA)\(stringB)")?
Тесты в iOS: хороший, плохой, …