Зачем писать тесты?
Прежде чем мы обсудим, что влечет за собой разработка через тестирование, важно понять, почему мы пишем тесты для приложения или программного обеспечения. Мы столкнемся с серьезными проблемами в будущем, если будем ожидать, что наше приложение Django будет действовать определенным образом при внесении изменений в кодовую базу без каких-либо тестов.
Тесты могут быть ручными или автоматизированными. Мы можем протестировать каждую функциональность вручную в сценарии с небольшим приложением. Примером этого может быть личный веб-сайт или блог с очень мелкой функциональностью.
В ручных тестах программисты активно тестируют каждую часть приложения. Мы делаем это, чтобы убедиться, что все работает должным образом, когда мы вносим изменения в кодовую базу. Однако с этим быстро становится трудно справиться по мере роста проекта.
Поэтому у нас есть концепция автоматизированных тестов, когда мы пишем код, который пытается имитировать настоящий ручной тест. Однако вместо того, чтобы мы активно тестировали его, компьютер тестирует его за нас.
Основные формы тестирования приложения
Клиентские приложения, от которых зависит множество клиентов или пользователей, не могут позволить себе иметь серьезные ошибки, потому что это может привести к нескольким уязвимостям. Баги возникают из-за ошибок в программировании. Ошибки программирования являются естественной частью написания кода. Написание тестов может смягчить это, отлавливая такие ошибки до того, как код будет запущен. Написание тестов очень важно. Написание множества тестов неизбежно экономит нам время в долгосрочной перспективе.
Подходы к написанию автоматизированных тестов
Есть два подхода к написанию автоматизированных тестов для нашего приложения. Первый подход заключается в том, чтобы сначала написать код, а затем написать тесты. Этот подход довольно популярен, поскольку разработчики предпочитают сначала создать функциональность или функцию, прежде чем писать тесты, чтобы убедиться, что функция работает.
Однако у нас есть другой подход, когда мы пишем тесты до того, как напишем код. Это известно как разработка через тестирование (TDD) . Это означает, что разработка приложения определяется тестами, которые мы пишем. Поэтому мы не можем добавить функциональность или возможности без предварительного написания теста.
Основной посыл TDD — в разбиении больших задач на маленькие. Стандартный цикл разработки состоит из трёх этапов:
- Красная зона: На нём мы пишем тест, который точно упадёт с ожидаемой причиной. Если причина падения теста не совпадает с ожидаемой, переходить к реализации функциональности рано.
- Зелёная зона: На нём пишем функцию, которая проходит этот тест. Цикл короткий, поэтому реализация должна быть максимально простой.
- Синяя зона: На этом этапе мы рефакторим код тестов и реализации. Проводить рефакторинг в этой зоне безопасно, потому что вся функциональность, которую рефакторинг затрагивает, уже покрыта тестами. Если что‑то по пути сломается, мы об этом тут же узнаем.
Появление разработки через тестирование
Термин «разработка через тестирование» был введен Кентом Беком в 2002 году в его книге «Разработка через тестирование на примере». С тех пор этот термин приобрел популярность в сфере веб-разработки. Несколько крупных корпораций используют эту технику из-за ее многочисленных преимуществ.
Однако внедрение TDD не происходит само собой. Разработчик должен приложить сознательные усилия. Это связано с тем, что большинство разработчиков предпочитают сначала кодировать функциональность приложения, прежде чем тестировать его. Таким образом, мы можем сказать, что TDD похожа на дисциплину, которую нужно культивировать.
