У разработчиков при упоминании покрытия тестами их продукта сразу возникают вопросы:
- Что именно тестировать?
- Какое должно быть покрытие?
- Каких тестов должно быть больше?
И часто пытаются использовать популярную пирамиду тестирования
Я в ней увидел, что основа это Unit тесты на которых все держится. Unit тестов должно быть много, а UI/API мало. Пописав много тестов я пришел к расширению этой диаграммы и добавил в нее оси по которым можно ориентироваться.
Используя этот рисунок мы можем ответить на несколко вопросов и прийти к выводу что-же нам нужно делать.
- Чтем пользуются ваши конечные пользователи продукта?
- Пишите продукт с нуля, то на сколько важна скорость доставки?
- Внедряете тестерование уже в существующий проект, то какая сложность существующего проекта?
- Какое количество у вас есть ресурсов которое можно потратить на тестирование?
Начнем последовательно отвечать на них используя матрицу из двух крайностей где соблюдается принцип Паррето 80/20.
Чем пользуются ваши конечные пользователи продукта? Link to heading
Если у вас web приложение, то конечный пользователь использует либо api или frontend приложение.
Если вы пишите библиотеку которую потом используют другие программисты, то конечный пользователь использует интерфейсы/методы которые он вызывает у себя в коде.
| Вопрос | UNIT | UI/API |
|---|---|---|
| api или frontend приложение | X | |
| интерфейсы/методы которые он вызывает у себя в коде | X |
Если пишите продукт с нуля, то на сколько важна скорость доставки? Link to heading
В стартапах которые еще не нашли как зарабатывать деньги и буюджет ограничен, скорость доставки может влиять на жизнеспособность проекта.
В заказных проектах которые живут за деньги заказчика и заказчик точно знает что хочет получить и за какой срок можно можно определить направление для тестов.
По моиему опыту написание unit тестов занимает минимум половину времени на разработку функционала. При написании UI/API забирает 20% верени.
| Вопрос | UNIT | UI/API |
|---|---|---|
| Скорость доставки важна | X | |
| Качество кода важно | X | X |
Внедряете тестерование уже в существующий проект, то какая сложность существующего проекта? Link to heading
Если у вас большой проект который разрабатывается давно и без тестов, то вам однозначно надо начинать с верху, иначе пользы от тестов вы еще не скоро получите.
Если прокет маленький и цена unit тестов не слишком отличается от api, то можно делать все.
| Вопрос | UNIT | UI/API |
|---|---|---|
| Проект большой | X | |
| маленький проект | X | X |
Какое количество у вас есть ресурсов которое можно потратить на тестирование? Link to heading
Когда компания готова уделять много ресурсов на стабильность и понятность проекта для разработчиков то конечно тестов нужно писать много.
| Вопрос | UNIT | UI/API |
|---|---|---|
| Много ресурсов | X | X |
| Мало ресурсов | X |
Сведем наши крестики в одну таблицу Link to heading
Поставив крестики в тех местах где ваш проек соответствует и посчитать сколько пользы вы получите от автотестов.
| Вопрос | UNIT | UI/API | Мой продукт |
|---|---|---|---|
| api или frontend приложение | X | X | |
| интерфейсы/методы которые он вызывает у себя в коде | X | ||
| Скорость доставки важна | X | X | |
| Качество кода важно | X | X | X |
| Проект большой | X | X | |
| маленький проект | X | X | |
| Много ресурсов | X | X | |
| Мало ресурсов | X |
По итогу у меня получилось 4 UI/API и 1 Unit тесты. Для моего проекта больше гараздо больше пользы принесет UI/API тесты.