Привет, меня зовут Сергей, и я инженер автоматизации тестирования.
Не так давно (13 Сентября 2023) на Хабре опубликовали статью "Подборка выдающихся статей по тестированию". В приведенном списке есть и статья "Фетиш юнит-тестов" Мартина Сустрика.
Я считаю эту статью вредной, и постараюсь показать – чем именно. Кто-то из читателей согласен с утверждениями Мартина. Возможно, кто-то из них не смотрел с позиции QA на эти утверждения. Именно для них я изложил свою точку зрения.
Я не буду приводить обширных цитат из оригинальной статьи, поэтому рекомендую перед дальнейшим чтением ознакомиться с её содержанием. Это не займет много времени – она короткая.
1. Return on investment of unit tests is an order(s) of magnitude lower than that of end-to-end tests
Автор утверждает, что ROI unit-тестов значительно (на порядок) ниже, чем E2E. Тут кажется странным несколько вещей.
Если сравнивается окупаемость ручного и автоматизированного тестирования, то, разумеется, ручное тестирование на короткой дистанции имеет более высокий ROI. Но, когда количество необходимого времени на исполнение регрессионного набора достигает определенных значений, и ROI уверенно снижается - положение спасает именно автоматизация. А если говорится об автоматизированных E2E-тестах, то автор попросту вводит в заблуждение читателей. Автоматизация E2E-тестов является наиболее дорогой автоматизацией, которую весьма невыгодно внедрять на начальных этапах проекта.
Также говорится о начале процесса QA, и при этом выносится за скобки методология и стадия разработки. Если используется TDD, то unit-тесты становятся неотъемлемой частью проекта. Рекомендую ознакомиться с исследованием "An Initial Investigation of Test Driven Development in Industry" Боби Джорджа и Лори Уильямса. В нём весьма убедительно показано, что инвестиции в TDD (соответственно, в unit-тесты) имеют большую окупаемость (если говорить о качестве), чем тестирование "черным ящиком". Помимо этого, если проект только начался, то о каком E2E-тестировании может идти речь?
Наиболее вредным в этом утверждении является то, что ответственность за проверку качества продукта полностью передаётся команде тестирования (им же выполнять E2E тестирование). Качественный продукт является плодом совместных усилий команды программистов, тестировщиков, аналитиков. И QA-инженеры призваны следить за тем, чтобы процессы верификации, валидации выполнялись всеми, и на всех этапах разработки продукта.
2. End-to-end tests test the critical path. Unit test do not
Автор утверждает, что E2E тесты проверяют критически-важные сценарии, а unit-тесты нет.
Это действительно так. Но без unit-тестов нужно несравнимо больше тестовых сценариев. А это значит, что требуемые ресурсы команды растут с каждым выпуском мажорной версии продукта. Необходимо написать тестовые сценарии, составить необходимые тестовые наборы и исполнить их. А также тратить дополнительное время на поиск корневой причины провальных проверок. Поясню. При E2E, зачастую, неочевидно из-за дефекта какого модуля проверка провалилась. А хороший тестировщик при составлении баг-репорта должен указать конкретную область, которая имеет дефект. И чем точнее он это сделает, тем меньше времени нужно на исправление дефекта программистом.
Здесь же автор утверждает: "However, user wants the product to work in common cases in the first place." Да, пользователи этого хотят. Но как же часто пользователи используют продукт "неожиданными" способами. Причин много: проблемы UX, отсутствие опыта работы с подобными приложениями. И, в конце концов, наличие богатой фантазии или неуёмного желания экспериментировать.
Вредным в этом утверждении является то, что принижается (фактически отрицается) важность проверок исключительных ситуаций (негативных проверок).
3. Unit tests ossify the internal architecture
Автор утверждает, что unit-тесты становятся бесполезными или вредными при рефакторинге архитектуры приложения.
Но, позвольте, как раз при рефакторинге unit-тесты могут оказать неоценимую помощь разработчику. Они показывают, как этот код работает! Без них программисты обречены на рефакторинг legacy-кода. А теперь ответьте: какая причина чаще убивает желание изменить архитектуру приложения - необходимость переписать unit-тесты или legacy-код?
Хорошие unit-тесты покрывают не просто методы или модули (unit'ы), а именно функциональные блоки (units of work). Соответственно, при изменении архитектуры, зачастую, достаточно заменить вызываемый и результирующий метод. Не утверждаю, что это просто, но точно проще, чем переписать всю логику теста.
Unit of work — это сумма всех действий, которые происходят между вызовом метода приложения и единственным конечным результатом, который может наблюдать пользователь.
Вредным в этом утверждении является то, что автор находит оправдание плохой (закостенелой) архитектуре в наличии unit-тестов. Если архитектура имеет изъяны – исправьте это. А unit-тесты могут помочь вам. Red, Green, Refactor один из примеров такой помощи.
4. There are things that can't be unit-tested
С этим утверждением автора трудно спорить. Действительно, не всё может и должно быть покрыто unit-тестами. Но это же не является аргументом в пользу полного отказа от unit-тестирования, верно? Движемся дальше.
5. Some stuff has no rigorous acceptance criteria
Автор приводит в пример графический интерфейс пользователя и говорит, что в нем нет строгих критериев. А значит тестировать весьма затруднительно. Но графический интерфейс состоит из компонентов (поля ввода, радиокнопки, чекбоксы и т.д.), которые имеют требования и логику поведения. При каких-то условиях они должны становится неитерабельными для пользователя или невидимыми. Они могут иметь валидационную логику с выводом сообщений. Эти требования могут быть проверены не только ручным тестированием, но и unit-тестами.
Вредным в этом утверждении является то, что автор снова вверяет команде тестирования всю полноту ответственности за проверку того, что может быть весьма успешно проверено автоматически unit-тестами.
6. Unit tests are easy to measure and you should fear that
Автор предостерегает от использования таких метрик тестового покрытия, как количество тестов или количество строк покрытого ими кода, и не дает другие примеры метрик, которые работают лучше. Однако, можно привести следующие примеры: количество найденных дефектов с разбивкой по классам, количество дефектов, найденных за потраченное на тестирование время, и среднее количество дефектов на один тест. С этими и другими метриками вы можете познакомиться в книге "Code Complete" Стива МакКоннелла (ISBN: 0735619670).
Вредным в этом утверждении является то, что даётся бесполезный способ оценки покрытия без альтернатив. Если вы используете плохой инструмент - найдите лучше (они есть), а не страдайте.
Заключение
Нужно отдать должное автору за то, что в заключении он просит задумываться о той работе, которую читатель проделывает. Прошу об этом и я.
Unit-тесты - это мощный инструмент, который может быть использован в разных ситуациях, и с разной успешностью. Часто важность таких тестов сложно переоценить. И на столько же часто они могут быть совсем бесполезными. Ищите правильные подходы. Оценивайте степень влияния пока ещё несуществующих на вашем проекте unit-тестов на качество продукта. Даже если вы имеете негативный опыт в прошлом.
