Разница во времени между разработкой с юнит-тестами и без тестов

Я - индивидуальный разработчик с довольно ограниченной рабочей средой, где время разработки обычно колеблется от 1-4 недель на проект, в зависимости от требований, срочности или того и другого. В любой момент времени я занимаюсь примерно 3-4 проектами, некоторые из которых имеют временные рамки, которые пересекаются друг с другом.

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

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

Вопрос в том, сколько разницы во времени будет писать проверенный модулем код поверх непроверенного кода, и как эта разница во времени масштабируется по мере расширения области проекта?

Чем позже вы тестируете, тем больше стоит писать тесты.

Чем дольше живет ошибка, тем дороже ее исправить.

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

Будда учил мудрости среднего пути. Тесты хорошие. Есть такая вещь, как слишком много хорошего. Ключ в состоянии сказать, когда вы вышли из равновесия.

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

Каждая строка кода без тестов будет значительно сложнее отлаживать или переписывать.

Каждый тест, который вы напишите, займет время.

Каждая ошибка займет время, чтобы исправить.

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

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

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

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

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

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

Я согласен с остальными ответами, но чтобы ответить на вопрос о разнице во времени напрямую.

Рой Ошеров в своей книге «Искусство модульного тестирования, второе издание», стр. 200, рассмотрел пример реализации проектов одинакового размера с похожими командами (по навыкам) для двух разных клиентов, где одна команда проводила тестирование, а другая - нет.

Его результаты были такими:

Таким образом, в конце проекта вы получаете меньше времени и меньше ошибок. Это, конечно, зависит от того, насколько большой проект.

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

Результатами исследования стали увеличение времени разработки на 15–35% (что далеко не соответствует 2-кратному значению, которое часто цитируют критики TDD), а также снижение плотности дефектов перед выпуском с 40% до 90% (! ). Обратите внимание, что у всех команд не было предшествующего опыта работы с TDD, поэтому можно предположить, что увеличение времени может, по крайней мере, частично объясняться обучением, и, таким образом, со временем будет снижаться, но это не было оценено в исследовании.

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

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

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

1. Изменить код
2. Скомпилировать приложение
3. Запустить приложение
4. Войти в приложение
5. Открыть окно
6. Выберите элемент из этого окна, чтобы открыть другое окно
7. Установите некоторые элементы управления в этом окне и нажмите кнопку

И, конечно же, после всего этого обычно требовалось несколько поездок в оба конца, чтобы понять это правильно.

А что если я использую модульные тесты? Тогда процесс выглядит больше как:

1. Написать тест
2. Запустите тесты, убедитесь, что это не удалось ожидаемым образом
3. Написать код
4. Запустите тесты еще раз, убедитесь, что все прошло

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

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

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

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

Таким образом, вопрос, который нужно задать, решая, следует ли (или какого рода) тестировать функцию / метод, задайте себе вопрос: «Какую ценность для конечного пользователя я создаю / защищаю этим тестом?». Если вы не можете ответить на этот вопрос, не покладая рук , то этот тест, скорее всего, не стоит затрат на написание / сопровождение. (или вы не понимаете проблемную область, которая является гораздо более серьезной проблемой, чем отсутствие тестов).

http://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Это зависит от человека, а также от сложности и формы кода, с которым вы работаете.

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

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

Вопрос в том, сколько разницы во времени будет писать проверенный модулем код поверх непроверенного кода, и как эта разница во времени масштабируется по мере расширения области проекта?

Проблема усугубляется с возрастом проекта: потому что всякий раз, когда вы добавляете новые функциональные возможности и / или всякий раз, когда вы реорганизуете существующую реализацию, вы должны повторно протестировать то, что было ранее протестировано, чтобы убедиться, что оно все еще работает. Таким образом, для долгосрочного (многолетнего) проекта вам может потребоваться не только протестировать функциональность, но и повторно протестировать ее 100 и более раз. По этой причине вы можете воспользоваться автоматизированными тестами. Тем не менее, IMO достаточно (или даже лучше), если это автоматические системные тесты, а не автоматические модульные тесты.

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

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

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

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

Лучший вопрос может быть:

• Является ли юнит-тестирование правильным видом тестирования, которое вам необходимо, чтобы избежать «значительного количества ошибок», которые вы производили?
• Есть ли другие механизмы контроля / улучшения качества (кроме модульного тестирования), которые можно рекомендовать или вместо них?

Обучение - это двухэтапный процесс: научитесь делать это достаточно хорошо, а затем научитесь делать это быстрее.

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

• Дополнительные преимущества / дополнительные расходы зависят от опыта написания юнит-тестов
  • с моим первым проектом модульного тестирования дополнительные расходы утроились, потому что мне пришлось многому научиться и я допустил много ошибок.
  • после 10 лет опыта работы с tdd мне нужно на 25% больше времени для написания тестов.
• с большим количеством tdd-модулей все еще требуется ручное тестирование и тестирование интеграции
• ТДД работает только тогда, когда сделано с самого начала.
  • применение tdd к существующему, расширенному проекту - дорого / сложно. Но вы можете вместо этого реализовать регрессионные тесты.
• Автоматические тесты (юнит-тесты и другие виды тестов) требуют, чтобы mantanace const поддерживал их работу.
  • создание теста с помощью функции копирования и вставки может сделать тест-код дорогостоящим.
  • С ростом опыта тестовый код становится более модульным и более простым в обслуживании.
• с ростом опыта вы будете чувствовать, когда стоит создавать автоматизированные тесты, а когда нет.
  • Например, нет ничего хорошего в том, чтобы юниттест простые геттеры / сеттеры / обертки
  • я не пишу автоматизированные тесты через графический интерфейс
  • я забочусь о том, что бизнес-уровень может быть проверен

Резюме

Начиная с tdd, трудно достичь состояния «больше выгоды, чем затрат», если вы находитесь в «ограниченной рабочей среде», особенно если есть «умные менеджеры», которые говорят вам «избавиться от дорогого, бесполезного тестирование "

Примечание: под «модульным тестированием» я подразумеваю «модули тестирования в изоляции».

Примечание: под «регрессионным тестированием» я имею в виду

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

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

Не писать тесты, очень похоже на кредитную карту; мы склонны тратить больше или писать больше кода. Больше кода имеет больше ошибок.

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

Начни медленно. Построй беглость, прежде чем судить. Вы всегда можете остановиться.

Совет программистов продвигал TDD и другие методологии тестирования уже давно, я не буду вспоминать их аргументы и соглашаться с ними, но здесь следует учесть дополнительные моменты, которые должны немного нюансировать:

• Тестирование не так удобно и эффективно в зависимости от контекста. Я занимаюсь разработкой веб-программного обеспечения, скажите, есть ли у вас программа для тестирования всего пользовательского интерфейса ... сейчас я программирую макросы Excel, должен ли я действительно разработать тестовый модуль в VBA?
• Написание и сопровождение тестового программного обеспечения - это реальная работа, которая рассчитывает в краткосрочной перспективе (в долгосрочной перспективе она окупается). Написание соответствующих тестов также является опытом, чтобы получить
• Работа в команде и работа в одиночку, не имеют одинаковых требований к тестам, потому что в команде вам нужно проверять, понимать и передавать код, который вы не написали.

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

Часто упускаемое преимущество TDD заключается в том, что тесты служат гарантией того, что вы не вносите новые ошибки при внесении изменений.

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

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

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

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

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

Частично это улучшение заключалось в том, что у меня было меньше производственных ошибок, что, в свою очередь, приводило к меньшему количеству прерываний -> У меня была лучшая концентрация в любой момент времени.

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

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

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

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

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

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