TDD. в любом случае сначала проверить?

Question

Вы все равно сначала делаете тест? Или в некоторых случаях вы делаете кодирование, а затем пишете свои тесты, чтобы убедиться, что код работает? Что касается меня, я предпочитаю создать класс. Конечно, во время создания класса я думаю об этом s interface and how to test the class. But I don Сначала пишу тестовый код. Вы пишете это первым? Как вы думаете, вы всегда должны сначала написать тестовый код?

Answer 1

Я не пурист в этом вопросе (TDD включает в себя больше, чем просто написание тестов в первую очередь, это также о первоначальном написании очень минимальных, жестко закодированных тестов и их рефакторинге - см. The Book от Мастер сам).

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

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

И, как только я начинаю чувствовать себя довольным тем, что у меня есть, и, таким образом, начинаю писать тесты, мне не обязательно переделывать «исследовательский» код с нуля (так как я сохраняю его чистым и пригодным для использования на ходу, не так уж сложно сделать, особенно в Python, но также в R и других гибких языках).

Answer 2

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

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

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

Answer 3

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

• Какими должны быть ваши критерии приемки?
• Когда ваш код будет «выполнен» и как он будет определен?

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

Итак, независимо от того, пишете ли вы сначала функцию, а затем пишете для нее модульный тест, или вы решаете сначала написать тест, а затем кодировать функцию, она имеет вторичный характер. После того, как вы продумали и задокументировали свои критерии приемлемости, ваша выгода будет состоять в том, что ваша цель станет более четкой, и вы с большей вероятностью сосредоточитесь на выполнении критериев приемлемости, сводя к минимуму любой «шум» (например, было бы неплохо добавить функцию x, Я все сделал).

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

Answer 4

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

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

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

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