Является ли тестирование единиц стоимостью усилий?

Ответ 1

Каждый день в нашем офисе происходит обмен, который выглядит примерно так:

"Человек, мне просто нравятся модульные тесты, я только что смог сделать кучу изменений в том, как что-то работает, а затем смог подтвердить, что я ничего не сломал, проверив тест снова..."

Подробности меняются ежедневно, но настроение не меняется. Модульные тесты и тестовое развитие (TDD) имеют так много скрытых и личных преимуществ, а также очевидные, которые вы просто не можете объяснить кому-то, пока они не сделают это сами.

Но, игнорируя это, вот моя попытка!

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

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

• Тесты и код работают вместе для достижения лучшего кода. Ваш код может быть плохой/багги. Ваш ТЕСТ может быть плохой/багги. В TDD вы полагаетесь на вероятность того, что оба будут плохо/ошибочно малы. Часто это тест, который нуждается в исправлении, но который все еще является хорошим результатом.

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

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

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

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

• Я думаю, что это был Фаулер, который сказал: "Несовершенные тесты, часто выполняемые, намного лучше, чем совершенные тесты, которые никогда не написаны вообще". Я интерпретирую это как предоставление мне разрешения на запись тестов, где я думаю, что они будут наиболее полезными, даже если остальная часть моего кода будет ужасно неполной.

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

• Ед. тесты помогают с повторным использованием кода. Перенесите оба ваших кода и ваши тесты в свой новый проект. Обновите код до повторного запуска тестов.

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

Ответ 2

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

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

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

Итак, чтобы ответить на ваш вопрос, Unit Testing обычно стоит усилий, но требуемое количество усилий не будет одинаковым для всех. Для тестирования модулей может потребоваться огромное количество если вы имеете дело с базой кодов спагетти в компании, которая фактически не ценит качество кода. (Многие менеджеры будут петь оценки Unit Testing, но это не значит, что они будут придерживаться этого, когда это имеет значение.)

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

Ответ 3

Лучший способ убедить... найти ошибку, написать unit test для этого, исправить ошибку.

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

Если вы сделаете это достаточно, другие быстро поймают.

Ответ 4

thetalkingwalnut спрашивает:

Каковы некоторые хорошие способы убедить скептически настроенных разработчиков в команде значения Unit Testing?

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

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

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

• Они могут пропустить запись теста для метода, если у них есть хороший аргумент, почему он не нужен (например, слишком просто, чтобы стоить того или слишком сложно, чтобы это стоило) и как метод будет в противном случае (например, проверка, утверждения, формальные методы, интерактивные/интеграционные тесты). Им необходимо учитывать, что некоторые проверки, такие как проверки и формальные доказательства, выполняются в определенный момент времени, а затем их необходимо повторять каждый раз, когда производственный код изменяется, тогда как модульные тесты и утверждения могут использоваться в качестве регрессионных тестов (записываются один раз и выполняются повторно после этого). Иногда я соглашаюсь с ними, но чаще я буду обсуждать, действительно ли метод слишком прост или слишком сложный для unit test.

  • Если разработчик утверждает, что метод кажется слишком простым в сбое, не стоит ли занять 60 секунд, чтобы написать для него простой 5-строчный unit test? Эти 5 строк кода будут запускаться каждую ночь (вы делаете ночную сборку, не так ли?) В течение следующего года или более и будете стоить усилий, даже если однажды это произойдет, чтобы поймать проблему, которая, возможно, заняла 15 минут или дольше, чтобы идентифицировать и отладки. Кроме того, при написании простых модульных тестов увеличивается количество модульных тестов, что делает разработчик хорошо выглядеть.

  • С другой стороны, если разработчик утверждает, что метод кажется слишком сложным для unit test (не стоит значительных усилий), возможно, это хороший признак того, что метод нужно разделить или реорганизовать для проверки легких деталей. Обычно это методы, которые полагаются на необычные ресурсы, такие как одиночные, текущее время или внешние ресурсы, такие как набор результатов базы данных. Эти методы обычно необходимо реорганизовать в метод, который получает ресурс (например, вызовы getTime()) и метод, который принимает ресурс в качестве аргумента (например, принимает временную метку в качестве параметра). Я позволил им пропустить тестирование метода, который извлекает ресурс, и вместо этого пишем unit test для метода, который теперь берет ресурс в качестве аргумента. Обычно это делает запись unit test намного проще и поэтому стоит писать.

• Разработчик должен нарисовать "линию на песке" в том, насколько всеобъемлющими будут их модульные тесты. Позже в разработке, всякий раз, когда мы находим ошибку, они должны определить, поймали бы проблему более полные модульные тесты. Если это так, и если такие ошибки возникают неоднократно, им нужно переместить "линию" в сторону написания более подробных модульных тестов в будущем (начиная с добавления или расширения unit test для текущей ошибки). Им нужно найти правильный баланс.

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

Однако нам нужно понять влияние "дополнительных модульных тестов". Разработчик может писать ~ N строк кода в неделю, и вам нужно выяснить, какой процент от этого кода должен быть unit test кода и производственного кода. На лёгком рабочем месте может быть 10% кода в качестве модульных тестов и 90% кода в качестве производственного кода, что приводит к продукту с множеством (хотя и очень багги) функций (думаю, MS Word). С другой стороны, строгий магазин с 90% модульными испытаниями и 10-процентным производственным кодом будет иметь твердотельный продукт с очень небольшим количеством функций (подумайте "vi" ). Вы никогда не услышите сообщений о последнем сбое продукта, но это, скорее всего, имеет отношение к тому, что продукт не очень хорошо продается, так как он имеет отношение к качеству кода.

Хуже того, возможно, единственная уверенность в разработке программного обеспечения заключается в том, что "изменение неизбежно". Предположим, что строгий магазин (90% модульных тестов/производственный код 10%) создает продукт, который имеет ровно 2 функции (при условии, что 5% от производственного кода == 1). Если клиент приходит и меняет 1 из функций, то это изменение уничтожает 50% кода (45% от единичных тестов и 5% от производственного кода). В магазине lax (10% модульных тестов /90% кода продукции) есть продукт с 18 функциями, ни одна из которых не работает очень хорошо. Их клиент полностью обновляет требования к 4 своим функциям. Несмотря на то, что это изменение в 4 раза больше, только половина базы кода теряется (~ 25% = ~ 4,4% модульных тестов + 20% от производственного кода).

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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

Ответ 8

Вы должны проверить как можно меньше!

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

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

Ответ 9

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

Ответ 10

[Я имею в виду, что я не могу видеть выше]

"Все модульные тесты, они не обязательно реализуют это - ФАКТ"

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

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

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

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

Ответ 11

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

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

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

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

Изменения не будут происходить в течение ночи, но с небольшим количеством терпения вы можете достичь своей цели.

Ответ 12

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

Ответ 13

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

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

Классическим примером этого в моем сознании является SqlDataReader, встроенный в страницу ASPX, связанную с GridView. Код находится в файле ASPX. SQL хранится в хранимой процедуре. Что вы unit test? Если страница делает то, что она должна была делать, следует ли переделать ее на несколько слоев, чтобы у вас было что-то для автоматизации?

Ответ 14

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

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

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

Одним из последних советов будет не только unit test ваш код, но сначала начните тест (см. TDD и BDD для более)

Ответ 15

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

Ответ 16

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

Я работаю над проектом прямо сейчас... это несколько TDD, и у нас есть большинство наших бизнес-правил, инкапсулированных как тесты... у нас около 500 или около того модульных тестов прямо сейчас. В прошлой итерации мне пришлось обновить наш источник данных и как наше настольное приложение взаимодействует с этим источником данных. Взял меня пару дней, все время я просто продолжал модульные тесты, чтобы увидеть, что я сломал и исправил. Изменить; Создавайте и запускайте свои тесты; исправить то, что вы сломали. Промыть, промыть, повторить, если необходимо. То, что традиционно принимало дни QA и нагрузки на лодку от стресса, было скорее коротким и приятным опытом.

Подготовитесь вперед, немного приложите дополнительные усилия, и он заплатит в 10 раз позже, когда вам придется начинать работать с основными функциями/функциями.

Я купил эту книгу - это Библия xUnit Testing knowledge - это, вероятно, одна из самых ссылочных книг на моей полке, и я ежедневно ее консультирую: текст ссылки

Ответ 17

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

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

Ответ 18

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

Я думаю, что модульные тесты оказываются полезными при написании api или фреймворков, которые должны длиться много лет и использоваться/модифицироваться/развиваться людьми, отличными от исходных кодеров.

Ответ 19

Тестирование единиц, безусловно, стоит усилий. К сожалению, вы выбрали сложный (но, к сожалению, общий) сценарий, в который его реализовать.

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

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

Ответ 20

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

Ответ 21

Я не знаю. Многие места не делают unit test, но качество кода хорошее. Microsoft делает unit test, но Билл Гейтс дал синий экран в своем выступлении.

Ответ 22

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

Вместо того, чтобы говорить об модульном тестировании с контрольной точки "test-after", мы должны посмотреть на истинное значение, обнаруженное при написании спецификации/теста/идеи до реализации.

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

Как первый тест изменил мою жизнь

Ответ 23

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

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

Ответ 24

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

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

и большой...

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

Ответ 25

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

Я также чувствую, что он улучшает мой стиль дизайна (гораздо больше ориентирован на интерфейс в случае, если мне нужно обманывать вещи вместе), и, как пишет зеленый пост в верхней части, он помогает с "кодированием запора": Знать, что писать дальше, или перед вами сложная задача, вы можете написать небольшую.

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

Ответ 26

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

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

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

Ответ 27

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

Ответ 28

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

Ответ 29

С пакетом unit test можно внести изменения в код, оставив остальную часть функций неповрежденной. Это большое преимущество. Используете ли вы unit test sutie и регрессионный набор тестов, когда вы заканчиваете кодирование новой функции.

Ответ 30

Единственное, что нужно помнить об модульном тестировании, - это то, что это комфорт для разработчика.

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

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