Другие причины для TDD: детские шаги, рентабельность инвестиций, синдром злого менеджера и наблюдение за сторожами.
Возможно, миру не нужны еще «Х причин для TDD», но я считаю, что большинство людей упускают из виду эти четыре очень важные причины для следования подходу «сначала тесты»:
- Шаги малыша
- рентабельность инвестиций
- Синдром злого менеджера
- Наблюдая за сторожами
Шаги малыша
Рабочий процесс TDD (разработка через тестирование) побуждает вас продвигаться вперед маленькими шажками. С этим рабочим процессом вы чувствуете себя маленьким сурикатом, который каждые несколько шагов встает, чтобы проверить свое окружение.
Возможно, не самый быстрый способ добраться до места назначения, но, без сомнения, самый безопасный. Но поскольку мы не рискуем быть съеденными, что значит для нас быть в большей безопасности?
После каждого небольшого изменения мы проверяем, не было ли внесено никакой ошибки. И если ошибка внесена, очевидно, когда и где она была введена: на последнем крошечном шаге.
Поиск ошибки становится тривиальным. А ошибки — это вторая по значимости трата времени в разработке программного обеспечения:
- Во-первых, вы тратите время на его написание.
- Затем кто-то должен проверить ошибку.
- Затем вы должны запустить его в производство.
- Ваш клиент должен сообщить об этом.
- Вы сортируете воздействие.
- Ваш менеджер должен расставить приоритеты.
- Вы должны заполнить какую-то задачу JIRA.
- Вы объясните это своему тестировщику.
- Вы должны отлаживать код, код, который к настоящему моменту, вероятно, совершенно чужд вам, поскольку, вероятно, прошли дни или недели с тех пор, как вы его написали.
- Потом исправишь.
- Кто-то проверяет исправление.
- И, наконец, вы выпускаете исправление в производство.
Так что, как это ни парадоксально, маленькие шаги и безопасность могут также означать, что вы будете двигаться быстрее, в зависимости от того, сколько ошибок вы записали.
На самом деле этот принцип точно такой же, как и Принцип «малых партий» в непрерывной доставке.
Мораль: если вы не пишете ошибки, не тратьте время на написание тестов.
Насколько маленькими должны быть детские шаги?
Как можно меньше, но его нижний предел будет зависеть от того, насколько быстр ваш набор тестов:
Даже если вы стараетесь очень дисциплинированно запускать тесты после каждого небольшого изменения, если ваш набор тестов работает медленно, вы в конечном итоге увеличите размер пакета изменений, просто чтобы избежать боли ожидания.
Следовательно, если вы хотите повлиять на частоту запуска тестов, вам нужно убедиться, что они выполняются очень быстро.
Возврат инвестиций (ROI)
Набор тестов — это инвестиция, и, как и в случае любой инвестиции, вы хотите получить высокую положительную отдачу от инвестиций (ROI). ROI можно рассчитать как:
ROI = (Прибыль от инвестиций — Стоимость инвестиций) / Стоимость инвестиций
Затраты на набор тестов довольно очевидны: время на его создание и поддержку. Также существуют постоянные затраты на его запуск (еще одна причина, по которой более быстрые наборы тестов лучше).
Набор тестов имеет несколько преимуществ, но мы можем суммировать их все как экономию времени при внесении изменений.
Таким образом, ROI набора тестов можно рассчитать как:
ROI = (сэкономленное время — потраченное время) / потраченное время
Если мы построим ROI (красным) с подходом «последний тест» при создании новой функции, мы можем представить что-то вроде:
Если вы больше никогда не коснетесь этой части кодовой базы, тесты станут худшим из ваших вложений, поскольку они не начнут окупаться, пока вы снова не начнете вносить изменения в эту конкретную область кодовой базы.
Давайте сравним его с подходом test-first:
Тесты начинают окупаться немедленно, так как вы активно меняете кодовую базу, охваченную этими тестами.
Мораль: если вы пишете тест, напишите его первым. Обратите внимание на выделенный если в предыдущем утверждении.
Синдром злого менеджера
«У меня нет времени на написание тестов» — вероятно, одно из наших любимых оправданий, когда нас спрашивают, почему наше покрытие кода далеко от идеального. Это не твоя вина, это вина твоего злого менеджера:
Manager: “We have to deliver yesterday!”
Team: “But we haven’t finished yet!!”
Manager: “Let cut some corners!!!”
Team: “Let’s skip writing the tests until we have time!!!!”
Manager: “Awesome! You are a fantastic team!!!!!”
И вот как обычно начинается спираль плачущего переписывания:
- Поскольку у вас мало тестов, вы не можете провести рефакторинг.
- Поскольку вы не можете проводить рефакторинг, ваша кодовая база начинает накапливать мусор.
- Чем больше мусора в вашей кодовой базе, тем больше времени требуется для реализации функций.
- Чем больше времени требуется для реализации функций, тем больше нехватка времени.
- Чем больше цейтнота, тем меньше тестов.
И это завершает нисходящую спираль, которая всегда заканчивается тем, что мы, разработчики, требуем полного переписывания.
Давайте посмотрим на ту же ситуацию, но при выполнении теста сначала:
Manager: “We have to deliver yesterday!”
Team: “But we haven’t finished yet!!”
Manager: “Let cut some corners!!!”
Team: “What features can we cut?!?!?!”
Manager: “Cutting features??? Do not write any tests!!!!!”
Team: “We already wrote them!!!!!!”
Manager: “Bastards!!!!!!!”
А дальше следует долгий разговор о том, какие функции урезать, которые ненавидит ваш менеджер. Добро пожаловать в Agile.
Наблюдая за сторожем
Наблюдение за провалом теста — это тест, который проверяет, проверяет ли тест то, что должен тестировать.
Или, проще говоря, как узнать, что в вашем тесте нет ошибок? Кто наблюдает за вашими сторожами?
Если вы сначала пишете тест и видите, что он не работает, это явный признак того, что какой-то фрагмент производственного кода, какая-то логика отсутствует.
Если вы пишете тест и никогда не видите, что он терпит неудачу, вы не знаете, связано ли это с тем, что вы уже реализовали функцию, или потому, что вы забыли об утверждении в своем тесте, или код установки неверен.
Мораль: написание тестов в первую очередь сохраняет честность сторожей.
Тест-сначала все вещи?
Но независимо от того, сколько у вас причин, когда вы представляете этот подход «сначала тесты», в большинстве случаев вы получаете зловещий ответ: «Как я могу сначала написать тесты, если я не знаю, что я собираюсь построить?»
И, как скажет вам любой опытный разработчик TDD, это чушь… но не всегда. В следующий раз мы увидим, когда TDD является лучшим подходом, а когда нет.
