На тест-ориентированной разработке, НО в ОБРАТНОЙ

Question

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

Answer 1

Если вы сначала не пишете свои тесты, то, возможно, это не TDD. С TDD вы обычно пишете тест, смотрите, как он проваливается, затем внедряете его, чтобы он прошел.

Преимущества перед вашим рабочим процессом:

• Ваши тесты могут провалиться! Слишком просто создать тест, который просто не может провалиться. И, как указывает Эрик, если вы сначала не пишете тест, а смотрите, как он проваливается, как вы узнаете, что тест на самом деле тестирует только что реализованную функциональность?
• Ваш код определённо тестируемый. Хотя я уверен, что вы следуете тестируемым методам, тестирование в первую очередь гарантирует, что код определенно тестируем, иначе вы бы не написали код: -)
• Переворачивает ваши решения "с ног на голову". Спорно один это, но TDD заставляет вас думать о том «что вам нужно», а не «детали реализации». Выполняя тесты, вы сначала объединяете общую архитектуру / структуру классов в своих тестах, а затем переходите к деталям реализации.

Вы можете уменьшить риски по всем этим пунктам, поэтому вам решать, хотите ли вы продолжать идти в том же духе или перейти к тестированию в первую очередь.

Answer 2

Если вы потом напишете тесты, действительно ли они стимулируют разработку / дизайн? Я бы так не думал.

Чтобы расширить ответ Стивена Роббинса: если ваш тест не провалится до того, как вы его пройдете, откуда вы знаете, что он проверяет правильность ?

Answer 3

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

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

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

Answer 4

Определяется ли дизайн соображениями испытаний? Если так, то тестирование привело к развитию. Что и должно произойти.

Написание тестов сначала абсолютно гарантирует, что тестирование стимулировало разработку. И это имеет тенденцию ограничивать рефакторинг.

Если вы хотите сначала написать весь код, а затем рефакторинг, вы используете тестирование для разработки (что хорошо). Тем не менее, вы, вероятно, тратите время, написав весь код сначала только для того, чтобы потом все реорганизовать (что не так хорошо). Использование TDD облегчит это; написание тестов до того, как код также сократит время разработки, сэкономив некоторые рефакторинг.

Answer 5

Я занимаюсь TDD (правильно) с 2000 года. Есть много хороших моментов, о которых упоминали другие, но один момент, который очень важен и отсутствует в других описаниях:

TDD заставляет вас писать простой код!

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

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