Делюсь своим опытом разработки мобильных приложений: про тестирование, доступность и UI.
Михаил Рубанов, @akaDuality
Post #1225
968
Пирамида тестов по покрытию
Пока готовился к Подлодке сделал слайд с анализом покрытия тестами внутри одного модуля. Пирамиду строил обратную: не по количеству тестов, а по степени покрытия, чтобы увидеть какой слой тестов какой импакт дает в целом.
Поделил на несколько слоев + измерил какое покрытие дают тесты такого типа (бледно) и сколько уникального покрытия на них приходится (ярко).
Вышло так:
• Общее покрытие в модуле — 81%. Не покрыт роутинг экранов и пара вьюшек с видео.
• Скриншот-тесты вьюшек дают 46%. Вьюшки проверяют и логику смены состояния во вьюмодели, поэтому через Prefire можно быстро покрыть половину кода только по превьюшкам. 30% уникального покрытия, что не получится зацепить другими тестами.
• Компонентные тесты покрывают 46%, дополнительно к вьюшкам это тестирует еще 17% кода. Они проверяют сценарии: тестируют координатор модуля, но так, чтобы еще вызывался код вьюмоделей по загрузке и действиям пользователя.
• Вьюмодели иногда нужно протестировать независимо: как фейлится загрузка, дополнительная логика внутри экрана. Много кода протестировано прошлыми тестами, поэтому тут лишь дополнительные 2.6%. Но если бы писали только такие тесты, то это бы покрывало 30% логики.
• Отдельные юнит-тесты по форматированию, обработке операций и т.п. Почти ничего не меняют глобально, но нужны по узким кейсам.
• UI-тесты не измерял, потому что не пишу их сейчас, но там скорее всего сумма скриншот-тестов и компонетных.
Это оценка поверх подхода к тестам, про которые рассказываю в книге: писать тесты так, чтобы повторять пользовательские сценарии, а не архитектурное деление на классы. Следствием идет большое покрытие, небольшое количество тестов. Не хорошо и не плохо, просто такой подход
https://bookshelf.dev/testing-book
Пока готовился к Подлодке сделал слайд с анализом покрытия тестами внутри одного модуля. Пирамиду строил обратную: не по количеству тестов, а по степени покрытия, чтобы увидеть какой слой тестов какой импакт дает в целом.
Поделил на несколько слоев + измерил какое покрытие дают тесты такого типа (бледно) и сколько уникального покрытия на них приходится (ярко).
Вышло так:
• Общее покрытие в модуле — 81%. Не покрыт роутинг экранов и пара вьюшек с видео.
• Скриншот-тесты вьюшек дают 46%. Вьюшки проверяют и логику смены состояния во вьюмодели, поэтому через Prefire можно быстро покрыть половину кода только по превьюшкам. 30% уникального покрытия, что не получится зацепить другими тестами.
• Компонентные тесты покрывают 46%, дополнительно к вьюшкам это тестирует еще 17% кода. Они проверяют сценарии: тестируют координатор модуля, но так, чтобы еще вызывался код вьюмоделей по загрузке и действиям пользователя.
• Вьюмодели иногда нужно протестировать независимо: как фейлится загрузка, дополнительная логика внутри экрана. Много кода протестировано прошлыми тестами, поэтому тут лишь дополнительные 2.6%. Но если бы писали только такие тесты, то это бы покрывало 30% логики.
• Отдельные юнит-тесты по форматированию, обработке операций и т.п. Почти ничего не меняют глобально, но нужны по узким кейсам.
• UI-тесты не измерял, потому что не пишу их сейчас, но там скорее всего сумма скриншот-тестов и компонетных.
Это оценка поверх подхода к тестам, про которые рассказываю в книге: писать тесты так, чтобы повторять пользовательские сценарии, а не архитектурное деление на классы. Следствием идет большое покрытие, небольшое количество тестов. Не хорошо и не плохо, просто такой подход
https://bookshelf.dev/testing-book
- 👍 9
- 🥴 5
- ❤ 2
