Как Вы поддерживаете дисциплину при выполнении TDD? [закрытый]

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

Я дам вам знать, когда найду метод, который работает. : -)

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

Я обнаружил, что полезно включить проверку покрытия кода как часть процесса сборки. . Если я не смогу написать тесты, сборка будет жаловаться на меня. Если я и дальше не буду писать тесты, сборка с непрерывной интеграцией выйдет из строя, и все поблизости услышат звук, который я подключил к уведомлению о «сломанной сборке». После нескольких недель «Хорошее горе ... Ты снова сломал?» И подобных комментариев, я вскоре начал писать больше тестов, чтобы избежать затруднений.

носить зеленый браслет

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

Если для добавления теста вам нужно сначала создать тестовый проект, а затем решить, как изолировать компоненты, когда имитировать вещи и т. Д., И т. Д. Он попадает в слишком сложную корзину.

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

1) Вы объединяетесь с кем-то еще в вашей команде . Один человек пишет тест, другой реализует.

Это называется спариванием «пинг-понг».

Выполнение этого заставит вас обсудить дизайн и решить, что делать.

Такое обсуждение также облегчит задачу. чтобы увидеть, какие тесты вам понадобятся.

2) Когда я работаю самостоятельно, мне нравится тестировать фрагменты кода в интерактивном режиме. Я просто набираю их в командной строке ruby. Когда я экспериментирую таким образом, мне часто нужно настроить некоторые данные для экспериментов и некоторые распечатки, чтобы увидеть, каков результат.

Эти небольшие самодостаточные одноразовые эксперименты обычно:

• быстрый способ установить осуществимость реализации и
• хорошее место для начала формализации теста.

Easiest way I've found is to just use TDD a lot. At some point, writing code without unit tests becomes a very, very nervous activity.

Also, try to focus on interaction or behavioral testing rather than state-based testing.

Когда я впервые начал заниматься TDD примерно в 2000 году, это было очень неестественно. Затем появилась первая версия .net и JUnit-порт NUnit, и я начал практиковать TDD на уровне Шу (из Shu-Ha-Ri ), что означало (сначала) все тестировать, с тем же вопросы как ваши.

Несколько лет спустя, на другом рабочем месте, вместе с очень преданным, компетентным старшим разработчиком, мы предприняли шаги, необходимые для достижения уровня Ха. Это означало, например, не вслепую смотреть на отчет о покрытии, а вопрос: «Действительно ли этот вид теста полезен и приносит ли он больше пользы, чем стоит?».

Теперь на другом рабочем месте вместе с еще одним замечательным коллега, я чувствую, что мы делаем наши первые шаги к уровню Ри. Для нас это в настоящее время означает большое внимание к BDD / исполняемым историям. Имея те, кто проверяет требования на более высоком уровне, я чувствую себя более продуктивным, поскольку мне не нужно (пере) писать кучу модульных тестов каждый раз, когда необходимо изменить публичный интерфейс класса, замените статический вызов на метод расширения и т. д.

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