Отношение времени потрачено на кодирование по сравнению с поблочным тестированием

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

• силы Вы для размышления о дизайне больше, и Вы склонны писать лучший код в результате
• позволяет Вам re-factor/maintain много месяцев/годы по линии, не боясь, Вы повредите все
• уменьшает полное проведенное время проекта, поскольку Вы не тратите впустую свое время, выслеживая тривиальные ошибки, которые поймало бы поблочное тестирование

Мое время о равном между временем для поблочного тестирования и время для функционального кода.

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

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

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

Но, Ваша экономия времени в тестировании времени НАМНОГО больше; Вы уже создали тесты для покрытия остальной части кода, таким образом, Вы раскрыли бы любые несущественные изменения, вытекающие из Вашего изменения без любого нового кода или обходящие приложение.

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

Когда Вы пытаетесь реализовать опции сверх существующей, кодовой базы "прежней версии" (поскольку Michael Feathers определил бы наследие), оно часто берет значительно дольше для реализования опции с тестами, чем без, должный на сумму тщательного рефакторинга, который должен быть сделан прежде, чем записать, что тесты обычно возможны. В этом случае запись тестов единиц будет все еще иметь долгосрочное преимущество, но необходимо поместить дополнительную мысль в то, выравнивается ли по ширине то долгосрочное преимущество для непосредственной стоимости.

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