UI тесты.
У нас они появились около года назад. Начинали их мы по большей части силами разработчиков. Сейчас больше ими занимаются уже QA.
Используем Espresso и пишем тесты на Kotlin. Тесты разбиты на 2 слоя.
Внутренний — работа с вьюшками и именно он у нас завязан на эспрессо.
Внешний: собственно код самого теста. Тут никаких зависимостей на сторонние фреймворк.
Так как в Kotlin есть такая штука как lambda with receiver код теста можно сделать максимально простым и легким для восприятия. kotlinlang.org/docs/lambdas.h…
Вот примерно так, как описано в статье. medium.com/android-bits/e…
У разделения на слои очевидный плюс: не нужно переписывать конечный тест, при не значительных изменениях дизайна. Или при переписывании вьюшки с xml на compose :)
Kotlin с dsl подходом добавляет еще один плюс: можно втянуть в автоматизацию QA, у которых до этого был либо минимальный опыт в автоматизацию, либо не было его вовсе.
Начать с того, что разработчики реализуют внутренний тестовый слой для некоторой фичи и пишут пару тестов в качестве примера. Затем QA дописывают остальные кейсы.
Постепенно QA начнут втягиваться, и со временем смогут писать тесты полностью. Во всяких сложных случаях может понадобится помощь разработчиков. Но с опытом таких ситуаций будет меньше.
Потом им может надоесть писать тесты и они захотят в разработчики, но до этого успеют принести пользу :)
Сделать тесты Espresso стабильными бывает не просто. Вот набор неплохих советов на тему medium.com/stepstone-tech…
Результат появления UI тестов для нас.
Релизы быстрее, особенно если изменения связаны с фичами для которых тесты уже есть.
Новые баги сильно чаще находятся там, где авто тестов пока нет.
Есть у вас UI тесты? Espresso (если речь про андроид)? Пишут сами разработчики или QA? На чём гоняются? Расскажите тоже что-нибудь из опыта :)
🤔
52.2% Есть!🤔
47.8% Нет :(