Если TDD о дизайне, зачем мне это? [закрыто]

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

TDD не только помогает мне прийти к лучшему окончательному дизайну, но и помогает получить меньше попыток.

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

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

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

Фундаментальная концепция намного старше, чем TDD; проектирование для проверки . Если вы строго придерживаетесь принципов SOLID , особенно принципа единой ответственности , вы найдете код, который очень легко протестировать. С другой стороны, если вы склонны к некоторой неаккуратности в своем дизайне, вы, вероятно, найдете процесс написания модульных тестов, чтобы заставить вас делать это чаще, чтобы избежать разочарования в (а) выяснении того, что необходимо быть проверенным и (б) тратить больше времени на настройку зависимостей, чем на написание реальных тестов.

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

Вы не можете знать, действительно ли вы разрабатываете для тестируемости, если вы не пишете тесты, и случайные «функциональные тесты» с только 15% охватом кода не учитываются.

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

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

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

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

• TDD заставляет меня задуматься перед внедрением, что, как правило, является очень хорошей практикой, которая предотвращает множество решений «забей и забудь»
• Это заставляет меня думать небольшими частями проблемы, заставляя меня разбивать решение на мелкие кусочки, которые сочетаются друг с другом.
• Это заставляет меня писать очень разрозненный код, потому что всякий раз, когда мне нужно заглушить / смоделировать / подделать что-то, что не вписывается в проблему, я естественно выбрасываю один «WTF, зачем мне это делать, если мне не нужно с этим связываться» , И это помогает мне лучше понять связь между вещами.
• Он дает мне набор легко исполняемых проверок для моего кода, поэтому мне не нужно проходить через болезненный стиль отладки кода «var_dump», «p», «pp», «echo». Он просто сообщает, что не так, когда не так. И если у меня еще нет проверки, просто добавьте простой тест, чтобы проверять его снова и снова.
• Я уверен, что мой код работает, если все тесты пройдут до того, как мы развернемся. Затем вместо того, чтобы есть свои ногти, я ем торт, пью кофе и наслаждаюсь днем.
• Тесты высокого уровня очень хороши в тех случаях, когда вам нужно что-то реорганизовать. Если мой модуль должен предоставлять некоторую функциональность внешнему миру, и я разработал функциональные тесты / тесты интеграции / огурца, чтобы доказать, что он работает правильно, я буду очень смелым, чтобы реорганизовать адский код. Несколько раз мне приходилось сталкиваться с кодом, который не имел тестов и должен был его реорганизовать. В этом случае было два пути на практике. 1) сбросьте код 2) пропустите изменения и оставьте все как есть.

Есть одна вещь, которую TDD не исправляет. Если вы не знаете, как создать то, что вы строите, то TDD не будет предлагать решение для вас. Вы должны иметь грубый «дизайн» или обзор проблемы и решения. TDD заставит вас реализовать его более элегантно и легко с помощью более качественного кода.

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

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

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