Поблочное тестирование - сколько еще время это действительно добавляет? [закрытый]

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

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

Верно ли это, особенно для новичков?

Смотря как. Перефразируя Бека (я думаю), если вы болван, инструменты / метамфетамин вам не помогут, если вы бог кодирования, они вам, вероятно, не нужны. Однако для большинства из нас, находящихся в середине, это помогает. По мере того, как вы двигаетесь вправо в этом спектре, все становится для вас второй натурой, вы должны «видеть», что происходит, и время начинает сокращаться (хотя и не до нуля). Чтобы избежать ошибок новичков, найдите кого-нибудь, кто уже был там (получите помощь из списка рассылки или наймите на время хорошего тренера)

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

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

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

Нет, если вы используете TDD, потому что:

• Фактически вы сначала пишете свой тест. Это само по себе большая экономия времени, так как вы заложили то, что собираетесь делать. Вы также точно знаете, когда прекратить кодирование. (Когда тест пройден)

• Когда вы на самом деле пишете код, он оказывается настолько маленьким, насколько это возможно. Вы можете прекратить кодирование после прохождения теста, а затем вы можете уверенно улучшить его, пока тест все еще проходит.

• Затем напишите тесты для крайних случаев (если необходимо) и проверьте, могут ли быть проблемы.

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

Думаю, это зависит ... от того, на какой объем тестового покрытия вы нацеливаетесь

Если вы намерены следовать истинному определению TDD, где каждая строка кода проверяется с помощью модуля тестовые примеры - возможно, вам требуются огромные усилия

Но не обязательно, чтобы

Вы могли найти свой собственный баланс ...

По моему опыту - я не обнаружил, что это удваивает время - хотя это и добавляет фактор (20-25%?)

Я имею в виду - даже если у вас не было случаев модульного тестирования - вы все равно выполняли бы модульное тестирование вручную, верно?

Со временем проект - вы увидите, что время, потраченное на модульные тесты, довольно легко компенсируется

Для клиентских проектов - ИМХО да. Надеемся, они оценят приложенные усилия

Я бы сказал, что время для написания автоматических модульных тестов зависит от вашего языка и того, как вы занимаетесь разработкой. Например, написание C # с очень процедурным стилем может затруднить разработку тестов. Однако, если вы выберете другой подход, скажем, используя некоторые фреймворки mocking и IOC, время модульного тестирования может значительно сократиться.

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

Я занимаюсь программированием в течение долгого времени и использую эти тесты в первую очередь для написания кода. Учитывая это, время на написание тестов практически ничего не добавляет к моему общему времени разработки. Если я пропущу написание тестов, которые я делаю, это «могло бы» сэкономить мне 10% моего времени в целом, если это так.

Когда я впервые начал использовать автоматическое тестирование, я бы сказал, что удвоение общего времени на написание кода составляет справедливая оценка. Но со временем я добился того, чего я не являюсь (почти не добавляя времени). Честно говоря, это это то, к чему вы привыкаете, и это становится частью того, как вы разрабатываете свой код в первую очередь.

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

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

От того, что вы тестируете, зависит, сколько времени это займет. Например, на написание модульного теста для TSQL с использованием среды модульного тестирования базы данных от MS у меня уходит гораздо больше времени, чем на создание хранимой процедуры, поскольку подготовка теста выполняется вручную.

Но если Я использую Eclipse или VS2008 для классов Java или C #, и я просто приказываю ему создавать тесты, а затем проводить тесты довольно быстро, поскольку большая часть рутинной работы выполняется за меня.

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

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

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

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

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

Что касается добавленного времени, раз вы упомянули, что вы новичок: чем раньше вы найдете набор модульного тестирования, который соответствует вашим потребностям, тем лучше. Вы не упомянули, какой язык вы используете, но если нет поддержки отражения (например, C, C ++), обычно требуется гораздо больше времени для настройки средств модульного тестирования, потому что вам нужно создать экземпляр TestSuite и Test, и вы должны зарегистрировать Test и т. Д. Это все, что нужно изучить, когда все, что вам нужно, - это запустить пару тестов!

С другой стороны, если вы используете Например, более динамичный язык, такой как Python, вы можете в значительной степени настроить модульные тесты, практически не зная о модульном тестировании, создав несколько методов testXXX с модулем unittest .

Что касается второго вопроса, поставьте себя на место клиента - разве вы не хотели бы услышать, что купленный вами товар был тщательно протестирован? Они (наверное) любят числа! Скажите им, что вы настроили автоматическое тестирование, было выполнено более 500 отдельных тестов, более 80% кода было протестировано таким образом - ну, скажите им только правду, но вы поняли. Это добавляет огромную ценность в плане надежности кода, и, честно говоря, я бы предпочел вести дела с кем-то, кто может продемонстрировать, что он знает , что было проверено и что может быть нестабильным, а не с кем-то, кто просто передает мне что-то и говорит: «Готово».

ve куплено было тщательно протестировано? Они (наверное) любят числа! Скажите им, что вы настроили автоматическое тестирование, было выполнено более 500 отдельных тестов, более 80% кода было протестировано таким образом - ну, скажите им только правду, но вы поняли. Это добавляет огромную ценность в плане надежности кода, и, честно говоря, я бы предпочел вести дела с кем-то, кто может продемонстрировать, что он знает , что было проверено и что может быть нестабильным, а не с кем-то, кто просто передает мне что-то и говорит: «Готово».

ve куплено было тщательно протестировано? Они (наверное) любят числа! Скажите им, что вы настроили автоматическое тестирование, было выполнено более 500 отдельных тестов, более 80% кода было протестировано таким образом - ну, скажите им только правду, но вы поняли. Это добавляет огромную ценность в плане надежности кода, и, честно говоря, я бы предпочел вести дела с кем-то, кто может продемонстрировать, что он знает , что было проверено и что может быть нестабильным, а не с кем-то, кто просто передает мне что-то и говорит: «Готово».