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

132

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

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

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

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

Потусторонние
источник
Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
maple_shaft
8
Вы решаете не ту проблему. Вы слишком заняты и, похоже, не имеете поддержки по управлению проектами. Вы оцениваете усилия по проекту? Вы резервируете 20% своего времени для исправления ошибок, встреч и других некодирующих задач? Сколько сверхурочных вы работаете?
Тони Эннис
20
Понимаете ли вы, что по сути дела говорите: «У меня есть время сделать это дважды, но не время, чтобы сделать это один раз правильно».
RubberDuck
5
@RubberDuck на самом деле есть точка на кривой сложности проекта, измеряемая как время записи против времени тестирования, где «дважды напиши», занимает меньше времени, чем «напиши и проверяй». Я думаю, что это может быть где-то в районе bash oneliner.
Линдон Уайт
Однажды разработчики получили подарки и спасибо, когда проект был отменен. Я указал, что мы могли бы быть еще более продуктивными, если бы знали, что продукт не будет поставляться. Таким образом, это тот случай, когда разработка без тестирования была бы выгодна.
JDługosz

Ответы:

148

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

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

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

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

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

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

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

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

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

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

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

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

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

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

candied_orange
источник
68
Есть такая вещь, как слишком много хорошего. Ни вы, ни Будда не проверяли печенья моей бабушки :-)
Пьер Арло
3
@NickAlexeev Я люблю эту таблицу там. Единственное, на что он не указывает, это то, что модульные тесты (которые обычно автоматизированы) действительно хороши в обнаружении ошибок при изменении кода. Я хотел бы видеть, что это разделено на "ошибки, найденные до выпуска" и "ошибки, найденные после выпуска". Модульные тесты - лучшая линия защиты от регрессии.
CorsiKa
3
Я думаю, что это очень сбалансированный ответ: тестирование всего, даже тривиальных вещей, может быть пустой тратой времени. Хорошие тесты для сложных частей, которые могут легко сломаться, могут действительно помочь. Я только что закончил перенос небольшого, но нетривиального проекта с Java на C ++. Сначала я портировал тесты, и это помогло мне настроить всю реализацию C ++. Когда все тесты были зелеными, нужно было перенести только несколько более легких классов, и все прошло довольно гладко. С другой стороны, у меня нет тестов для всего кода: это продлило бы реализацию по крайней мере на 3, 4 дня с небольшим выигрышем.
Джорджио
5
Небольшое несогласие с этим: «Вы должны сопоставить все это с тем фактом, что тесты не добавляют функций. Код добавляет функции. И особенности это то, что оплачивает счета. Я настоятельно рекомендую оплачивать счета не по функциям, а по функциональности. (или людям платят за нерабочие результаты?). С остальным ответом я полностью согласен.
Тони Саффолк 66
6
@ TonySuffolk66 Вы правы, это рабочие функции, которые оплачивают счета (исключая торговое мастерство), однако люди создавали рабочие функции задолго до того, как TDD стал чем-то особенным. Они будут долго после того, как он ушел. Помните, что TDD - это дисциплинированный способ тестирования. Это не единственный дисциплинированный способ тестирования.
candied_orange
112

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

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

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

Прогресс команды и результат измеряются с и без тестов

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

Аки К
источник
32
Размер выборки слишком мал, чтобы считать это научным, но я думаю, что он отражает то, что испытывает множество людей. Я обнаружил, что когда я делаю TDD, большая часть дополнительного времени уходит на исправление ошибок, которые приводят к сбою моих модульных тестов, а не на написание самих тестов. Это на самом деле не добавляет дополнительного времени, просто сдвигает, когда вы находите и исправляете эти проблемы. Любое дополнительное время заключается в устранении проблем, которые вы бы не нашли, по крайней мере, в первом раунде.
JimmyJames
7
@JimmyJames Это тематическое исследование, которое широко используется в бизнесе и в науке, когда (пока) невозможно провести крупномасштабный воспроизводимый эксперимент. Там полно журналов по психологии. «Ненаучный» не правильное слово.
Джечлин
25
Почему я думаю, что если бы результат этого исследования показал обратное, он бы не попал в книгу ;-)?
Док Браун
11
@DocBrown Интересно, сколько примеров было сделано и отброшено, прежде чем они нашли одно с правильными ответами :-)
gbjbaanb
6
@JimmyJames, который почти наверняка квалифицируется как наука. Кроме того, другой ученый может прочитать это исследование «n = 1», решить, стоит ли его изучать больше, а затем запустить крупномасштабное статистическое исследование или даже продольный эксперимент, и подтвердить или опровергнуть его. Именно так работает наука. Вот как это должно работать. Вы можете прочитать больше о том, как наука работает здесь en.wikipedia.org/wiki/Scientific_method
djechlin
30

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

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

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

Йорг Миттаг
источник
1
Было бы более интересно наложить дополнительные ограничения: нет изменяемого состояния, после SOLID, статическая типизация, не полагаться null, функционально над императивом, контракты кода, статический анализ, автоматический рефакторинг, нет IoC-контейнеров (кроме DI) и т. Д. Бьюсь об заклад, что это значение модульных тестов уменьшится (но не исчезнет).
День
24

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

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

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

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

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

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

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

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

Уинстон Эверт
источник
1
А использование чего-то вроде nCrunch может сократить шаги 2 и 4, делая петлю обратной связи еще более тесной.
Эйфорическая
«Мне все равно придется вручную запускать приложение», это важное наблюдение, ИМХО. Никаких серебряных пуль.
День
20

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

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

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

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

Джаред Смит
источник
1
Я не очень хорошо знаком с BDD, но предположу, что он работает с несколько большей степенью детализации, чем уровень метода / функции, и, вероятно, имеет менее слабую связь с пользовательской ценностью.
Джаред Смит
1
Связанный
Робби Ди
9
«Тестирование ради тестирования (тривиальные или тавтологические тесты) или попадания в какую-то произвольную метрику (например, покрытие кода) - это грубо-культовое программирование». Так верно и так хорошо сказано. Тестируйте так, чтобы вы чувствовали себя крутым идиотом - думайте о себе как о ... шпионе, элитном спортсмене ... НЕ проверяйте как "правительственный департамент". Ты знаешь?
Толстяк
2
@SteveJessop не согласен, покрытие кода (в смысле метрики) по своей природе произвольно: число путей через нетривиальную программу на уровне машинных инструкций (то есть тот, который считается) будет больше, чем число атомов на Земля или, возможно, даже видимая вселенная. Это не поддается проверке. Таким образом, любое требование «покрытия кода» будет иметь некоторый эвристически выбранный произвольный порог. Программисты хорошо разбираются в таких показателях за счет того, что действительно важно.
Джаред Смит
2
Я также сказал бы, что тесты обеспечивают бизнес-ценность приблизительно (хотя и не точно) каждый раз, когда они терпят неудачу, и решение заключается в улучшении тестируемого кода. Так что, если вы используете TDD, это происходит автоматически по крайней мере один раз за тест. Тавтологические тесты по определению не могут провалиться и поэтому бесполезны. Для «тривиальных» тестов - работая с Java TCK в начале своей карьеры, я больше не удивлен тем, насколько тривиальным может быть тест, если заново внедрить API с нуля ;-) Но бизнес-ценность почти всегда предсказывается эвристически, так же как и "произвольно".
Стив Джессоп
9

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

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

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

Telastyn
источник
7
Думаю, стоит отметить, что это приобретенный навык. Я вижу, что многие люди слышат утверждение о том, что TDD на самом деле даже не затрачивает время впустую, что окупается в долгосрочной перспективе, просто быстрее, и точка. затем они пробуют это в течение дня, и это больно, потому что у них 0 опыта, они прочитали 0 книг, нет практики, они просто ожидают, что это сработает волшебным образом. нет никакого секрета в TDD, который делает вас лучшим разработчиком, вам все еще нужно практиковаться, все еще нужно думать, все еще нужно принимать правильные образованные решения.
Сара
1
@kai - +1. Я потратил недели, читая о TDD, прежде чем я попробовал это. Я прочитал все, что мог найти. Я читаю книги. Я читаю все известные проворные блоги для примеров. Я читаю тестовые шаблоны xUnit от корки до корки. Первые несколько недель это все еще занимало у меня вдвое больше времени.
Жюль
2
Я согласен. TDD это сложно. Мышление сложное. Любой, кто говорит «Просто напиши сначала тесты» и заявляет, что это бесплатно, не знает, как это сделать. Это требует практики.
Даффимо
@kai: по тем же причинам многие люди не могут печатать. Они попробовали это один раз, и через час все еще не печатали быстрее, чем раньше ;-)
Стив Джессоп
@ SteveJessop Полагаю, это довольно аккуратное сравнение. Или быть действительно неподходящим и выходить на 10-минутную пробежку, изнуряться и удивляться, почему вы не можете пробежать 10 миль в час. это действительно показывает, как вам нужно работать, прежде чем вы получите преимущества.
Сара
4

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

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

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

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

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

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

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

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

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

ChrisW
источник
3

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

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

Резюме

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

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

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

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

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

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

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

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

JeffO
источник
3

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

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

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

Артур Гавличек
источник
1
«Должен ли я действительно разработать тестовый модуль для VBA?» Чертовски верно, ты должен. rubberduckvba.com/Features#unitTesting
RubberDuck
Есть несколько причин, по которым я не буду использовать это, потому что это не соответствует моим потребностям (я занимаюсь несколькими днями, заблокированная среда, преемник не будет беспокоить третьих лиц). Хороший комментарий, хотя язык не является оправданием сам по себе :)
Артур Гавличек
Все справедливые точки @ArthurHavlicek.
RubberDuck
2
Написание тестов все еще тривиально в VBA. Имеете все причудливые функции, которые есть у некоторых платформ unittest? Это сложнее, но запустить программу, mainTest()которая вызывает все ваши тестовые модули, не так уж сложно.
enderland
1

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

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

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

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

Робби Ди
источник
Эта вещь в вашем первом предложении называется регрессионное тестирование
кошка
0

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

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

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

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

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

Кристиан Зауэр
источник
0

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

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

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

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

RodolfoAP
источник