Рабочий процесс программирования с модульным тестированием, но без TDD

Question

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

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

Answer 1

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

Этот рабочий процесс делаетсмысл (для меня в любом случае).

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

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

Answer 2

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

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

Пара преимуществ TDD заключается в том, что, написав сначала тесты, вы получаете доказательство того, что они могут потерпеть неудачу (в противном случае вы могли бы случайно написать тест, который ВСЕГДА пройдет), и вы пишете тесты независимо от того, как вы пишетекод (так что вы с меньшей вероятностью будете писать тесты, которые содержат ту же логику, что и рабочий код - что бессмысленно).