Вы впервые слышите о TDD, и это от вашего профессора. Вас попросили внедрить TDD в проект, и, судя по всему, вам сложно сделать именно это. Вас беспокоит, как много времени уходит на написание теста перед решениями по кодированию, и заставляет задуматься, зачем вам вообще это делать. Следовательно, вы пришли к этой статье, ожидая беглого ознакомления с TDD и его преимуществами, верно? Не волнуйся! Мы и сделаем это!

Что такое TDD?

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

TDD - это процесс разработки программного обеспечения, в котором тесно переплетаются три основных аспекта программирования; кодирование, тестирование и рефакторинг - и у него есть собственный набор правил, а именно:

  1. Вы не можете писать производственный код, пока не напишете неудачный тестовый модуль.
  2. Пишите не больше модульного теста, чем достаточно, чтобы проиграть
  3. Пишите не больше производственного кода, чем необходимо для прохождения неудачного тестового модуля.

Хватит краткого объяснения, а теперь зададим вопрос -

Хорошо, но почему это важно?

Более быстрый отзыв, более быстрое исправление

Поскольку TDD служит своего рода обратной связью по программе, которую вы собираетесь создать, к моменту завершения процесса реализации у вас уже будет обратная связь об ошибках и т. Д .; какие направления реализации не прошли неудачный тест. Это позволяет вам исправлять код намного быстрее по сравнению с тем, когда ваш тест проводится через 1 месяц после завершения реализации. Сама по себе быстрая обратная связь дает вам большие преимущества при разработке программного обеспечения.

Каким-то образом гарантия того, что ваша программа соответствует видению вашего product owner-а

То есть вы построили тест на провал на основе критериев приемлемости пользовательских историй вашего проекта. Выполнив это и внедрив TDD, вы будете знать, что когда весь ваш тест пройден или помечен как ЗЕЛЕНЫЙ, это означает, что ваша программа соответствует критериям приемлемости всех пользовательских историй проекта, все, что остается, - это рефакторинг (и, возможно, некоторые новые проверяет, становитесь ли вы гибкими и на грани времени попросили изменить некоторые функции).

Не заставляет задуматься: «Что я снова делаю?»

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

Вам нужно сначала реализовать только A, а не A, B, C, D вместе

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

Безопасный рефакторинг, более чистый код

После того, как код, который вы внедрили, был признан успешным, вы перейдете к этапу рефакторинга. Рефакторинг требует, чтобы вы превратили этот беспорядок в уже реализованный код в более чистый и читаемый, не меняя поведения кода. Таким образом, вы можете сделать код более чистым без необходимости писать еще один тест, и некоторые из ваших коллег могут легче читать ваш код, в то время как ваш код по-прежнему имеет те же преимущества, что и проект TDD.

Потратьте время сейчас, сэкономьте время позже

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

Болит мозг, нужны примеры!

Конечно! вот простой пример TDD в моем командном проекте с использованием Django и HTML. В этом сценарии я хотел реализовать простую целевую страницу, состоящую из «HELLO WORLD» и панели навигации.

КРАСНЫЙ

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

Зеленый

Как только тест станет красным, пора реализовать программу. Во-первых, чтобы пройти тест шаблона, нам нужно создать шаблон с именем «index.html». Так и сделали:

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

Таким образом, когда тест пытается получить ответ от прохода «/», Django предоставит его, в результате чего будет получен код состояния 200.

Наконец, чтобы пройти проверку компонентов, нам нужно сделать компонент на index.html, включая панель навигации и HELLO WORLD, инкапсулированным с тегом h2.

Теперь все, что нам нужно сделать, это снова запустить тест.

Хорошо! Теперь, когда мы знаем, что он зеленый, нам нужно перепроверить наши коды, чтобы увидеть, нуждается ли какой-либо из них в рефакторинге. Если это так, то сделайте это, не заставляя код снова становиться КРАСНЫМ, в этом все-таки смысл рефакторинга.

Ух ты, TDD дает много преимуществ!

Да, TDD действительно действительно очень - и я говорю - очень важен. При работе над большим проектом разработчики, как правило, боятся прогрессировать или изменять свой код, потому что они не хотят создавать эффект бабочки, который может испортить весь проект. TDD убережет вас от этого самого эффекта. Он предоставит вам все перечисленные выше преимущества и заставит вас чувствовать себя в безопасности, зная, что что бы вы ни пытались изменить в коде, тест даст вам понять, делаете ли вы это неправильно или нет.

Так что да, насчет того проекта, который был поручен вашим профессором - вам обязательно нужно реализовать TDD на нем!