Зачем нужны юнит-тесты?
Частое заблуждение, что на мобилке юнит-тесты не нужны. Достаточно лишь е2е и UI.
На практике же е2е покрывает только пару успешных кейсов, забывая про остальные состояния флоу или функциональности. Он не выходит за границы UI и не погружается на уровни бизнес-логики. Его выполнение дорогое и долгое. Например, часто он не смотрит подгрузилась ли модель, закэширована ли сессия, правильны ли входящие/исходящие данные. Но он идеально подходит для проверки нескольких модулей.
Обычно е2е проходят по самому простому пути:
1. Выполняю флоу
2. Смотрю, есть ли текст, кнопка, вьюха в иерархии вьюх, которые видит пользователь.
А что там под копотом никто не хочет тестировать.
Любые тесты экономят вам время, документируют код, удешевляют разработку, помогают стабильно расти продукту. Все это ощущается на долгосрочной дистанции, когда вы устали протыкивать сложнейшие кейсы в тысячный раз. И самые дешевые — это юнит
Какова же цель юнит-тестирования?❓
Его цель — обеспечение стабильного роста программного проекта. Ключевым словом здесь является «стабильный». В начале жизни проекта развивать его довольно просто. Намного сложнее поддерживать это
развитие с прошествием времени.
❓Чем же хороши юнит тесты?
Документация тест-кейсов
Когда вся команда уходит и вместо нее приходит новая, или мы возвращаемся к коду, забытому несколько тысяч лет насад, тесты отлично помогают максимально точно описать поведение. Не выкапывая из памяти или тысяч устаревших документаций
Удешевление разработки
Стандартная тема, что после нескольких месяцев, лет разработки всех кейсов уже никто не помнит, часть людей меняется, требования противоречат коду. Ручных проверок слишком много. Тест позволяет найти баги на этапе разработки. Зафиксировать поведение и гарантировать, что этот кейс был проверен.
Ускорение разработки
Ну и понятно, что ручной кейс намного медленней, чем пару сотен миников
Но различия между хорошими и плохими тестами не ограничиваются вкусами. Далее разберемся в отличиях хорошего и плохого теста.
Частое заблуждение, что на мобилке юнит-тесты не нужны. Достаточно лишь е2е и UI.
На практике же е2е покрывает только пару успешных кейсов, забывая про остальные состояния флоу или функциональности. Он не выходит за границы UI и не погружается на уровни бизнес-логики. Его выполнение дорогое и долгое. Например, часто он не смотрит подгрузилась ли модель, закэширована ли сессия, правильны ли входящие/исходящие данные. Но он идеально подходит для проверки нескольких модулей.
Обычно е2е проходят по самому простому пути:
1. Выполняю флоу
2. Смотрю, есть ли текст, кнопка, вьюха в иерархии вьюх, которые видит пользователь.
А что там под копотом никто не хочет тестировать.
Любые тесты экономят вам время, документируют код, удешевляют разработку, помогают стабильно расти продукту. Все это ощущается на долгосрочной дистанции, когда вы устали протыкивать сложнейшие кейсы в тысячный раз. И самые дешевые — это юнит
Какова же цель юнит-тестирования?
Его цель — обеспечение стабильного роста программного проекта. Ключевым словом здесь является «стабильный». В начале жизни проекта развивать его довольно просто. Намного сложнее поддерживать это
развитие с прошествием времени.
❓Чем же хороши юнит тесты?
Документация тест-кейсов
Когда вся команда уходит и вместо нее приходит новая, или мы возвращаемся к коду, забытому несколько тысяч лет насад, тесты отлично помогают максимально точно описать поведение. Не выкапывая из памяти или тысяч устаревших документаций
Удешевление разработки
Стандартная тема, что после нескольких месяцев, лет разработки всех кейсов уже никто не помнит, часть людей меняется, требования противоречат коду. Ручных проверок слишком много. Тест позволяет найти баги на этапе разработки. Зафиксировать поведение и гарантировать, что этот кейс был проверен.
Ускорение разработки
Ну и понятно, что ручной кейс намного медленней, чем пару сотен миников
Но различия между хорошими и плохими тестами не ограничиваются вкусами. Далее разберемся в отличиях хорошего и плохого теста.