Учти это:

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

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

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

Регрессионное тестирование

Это все о регрессионном тестировании .

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

Отвлекаясь, он инвертирует две постоянные.

Он фиксирует код, и все, кажется, работает нормально, потому что нет регрессионного тестирования после каждого коммита.

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

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

Побочный эффект ...

На самом деле, большинство рефакторинга в значительной степени основано на регрессионном тестировании. Сделайте небольшое изменение. Тест. Если это пройдет, все в порядке.

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

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

Изменения в требованиях

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

Почему все это хлопотно? Зачем удалять тесты, чтобы добавить их позже? Вы могли бы сохранить их в первую очередь.

Потому что ничто не так просто, чтобы не было ошибок.

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

Кроме этого есть ошибка ...

public function polynominal($a, $b, $c, $d)
{
    return  $a * pow($x, 3) + $b * pow($x, 2) + $c * $x + $d;
}

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

Приложение:

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

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

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

Да. Если бы мы могли сказать с уверенностью 100%, с уверенностью: эта функция никогда не будет редактироваться и никогда не будет выполняться в контексте, который может вызвать ее сбой - если бы мы могли сказать это, мы могли бы отказаться от тестов и сэкономить несколько миллисекунд на каждом CI build.

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

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

Все сказанное в других ответах верно, но я добавлю еще один.

Документация

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

Это может облегчить обнаружение ошибки и уменьшить путаницу.

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

Пример того, насколько он может быть полезен в качестве документации, приведен во введении «Жасмин»: http://jasmine.github.io/edge/introduction.html Дайте ему несколько секунд для загрузки, затем прокрутите вниз. Вы увидите весь Jasmine API, документированный как результат модульного теста.

[Обновление на основе отзывов @Warbo] Тесты также гарантированно актуальны, так как в противном случае они не пройдут, что, как правило, приведет к сбою сборки, если используется CI. Внешняя документация изменяется независимо от кода и, следовательно, не обязательно обновляется.

Проверка на практике

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

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

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

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

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

Да, продолжайте тесты, поддерживайте их работу и поддерживайте их прохождение.

Модульные тесты предназначены для защиты вас (и других) от вас самих (и самих себя).

Почему держать тесты хорошей идеей;

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

Документация для разработчиков

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

Документация пользователя

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