Почему Важно Покрывать Код Тестами

Статья скопирована с www.zhashkevych.com.

Спасибо Максиму – за всё. Смотрите его Ютуб. Музычка. unsplash. Инста. linkedin.

Курс по Go


Внимание. Есть статья Максима посвежее


Сложно представить качественный программный продукт без должного покрытия кода тестами.

Они легко воспроизводимы, гарантируют корректное поведение отдельных компонентов и всей системы в целом, помогают отследить регрессию при изменении существующего кода, а также автоматизируют процесс проверки и выявления ошибок.

Хорошо написаные тесты, которые покрывают все позитивные и негативные сценарии, зачастую служат хорошей документацией кода и позволяют новым разработчикам быстрее разобраться с проектом и его логикой.

Хоть и написание тестов нередко бывает достаточно трудоемким процессом, которое может отнять у разработчиков много времени, оно обеспечивает безболезненную и быструю разработку системы в долгосрочной перспективе.

Уровни Тестирования

Существует несколько уровней тестирования, от unit тестов до тестирования UI. Эта концепция представлена в иерархическом виде в форме пирамиды Майком Конном в своей книге «Scrum: гибкая разработка ПО» (Succeeding With Agile. Software Development Using Scrum).

Пирамида трактует нам два принципа:

  1. Нужно писать тесты разной грануляции.
  2. Чем выше уровень, тем меньше тестов.

Важно усвоить различие между каждым уровнем пирамиды, чтобы писать качественные
тесты.

Unit тесты предназначены для тестирования отдельных независимых участков кода, которые реализуют определенное поведение.

Интеграционные тесты, в свою очередь, проверяют взаимодействие разных компонентов системы (работа с БД, сторонним АПИ и тд.) и корректную реализацию бизнес логики.

UI тесты же отвечают за проверку корректной работы системы с перспективы пользователя, т.е взаимодействие front и back -end компонентов приложения.

Также, следуя моей практике, в первую очередь при разработке новой системы стоит покрывать свой код юнит тестами. При реализации некой дополненной части бизнес логики можно заняться написанием интеграционных тестов. И только в последнюю очередь браться за разработку UI тестов.

То есть, проще говоря, стоит следовать структуре пирамиды и двигаться снизу-вверх при покрытии проекта тестами.

Тестирование и архитектура приложения

На моей практике проекты, на которых не было тестов вообще, обладали ужасной архитектурой и структурой проекта, а также кучей спагетти кода.

Архитектура приложения напрямую влияет на удобство разработки тестов, по этому наличие качественных тестов зачастую также и гарантирует соблюдение грамотных архитектурных решений.

Я приверженец подхода Чистой Архитектуры при построении приложений. Она позволяет отделить каждый слой приложения друг от друга, тем самым обеспечив слабую связность компонентов системы.

Это позволяет изолировать все слои системы (транспортный уровень, уровень бизнес логики, уровень хранилища) и безболезненно тестировать каждый из них, используя мокинг дополнительных зависимостей.

Подробнее о практической реализации данной архитектуры на языке Go вы можете узнать тут.

Подведем итоги

Тесты гарантируют корректность работы системы и дают нам, как разработчикам, уверенность в том, что все наши изменения и доработки в коде не ломают старый функционал.

Они помогают автоматизировать процесс выявления ошибок и быстро исправлять их.

Тесты зачастую служат самодостаточной документацией кода и бизнес логики приложения, тем самым позволяя новым разработчикам быстрее разобраться в особенностях и нюансах работы кода и системы в целом.

Архитектурные решения влияют на качество и удобство написания тестов и наоборот, присутствие тестов диктует нам как разработчикам грамотно подходить к реализации архитектуры, чтобы сделать систему удобной для тестирования.

Выходя из всего вышесказанного, при разработке относительно больших проектов, всегда держите в голове важность покрытия кода тестами.

Отсутствие тестов на проекте — это технический долг, который спустя некоторое время даст о себе знать и принесет много неприятностей в процессе разработки и постоянного деплоймента приложения.

Пишите качественный код и не забывайте покрывать его тестами. Чести и удачи!

02.05.2020

Связаться с автором Поддержать автора (что?)

Комментарии

Если у вас есть вопрос, критика или другое мнение - напишите в комментариях.