Соотношение времени, затраченного на кодирование, и модульного тестирования - PullRequest
9 голосов
/ 06 октября 2008

Какова типичная оценка для единичных тестов кодирования с учетом оценки для новых функциональных возможностей кодирования? Отличается ли оценка для поддержки кода?

Ответы [ 3 ]

9 голосов
/ 06 октября 2008

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

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

В любом случае время, потраченное на написание юнит-теста, фактически экономит время от суммы, которую я бы потратил на проект.

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

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

6 голосов
/ 06 октября 2008

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

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

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

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

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

...