Добавить юнит-тест для каждой новой ошибки

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

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

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

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

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

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

Абсолютно!

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

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

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

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

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

Попытка продать его в качестве регрессионного теста - проигранная битва, ИМХО. Учитывая, как редко эти вещи обнаруживают повторяющуюся ошибку, большинство разработчиков просто скажут: «Зачем беспокоиться, когда я могу просто исправить это?»

Этот метод довольно распространен, и, на мой взгляд, лучшее название для него - «Тестирование на основе дефектов» (я сам придумал его, а потом нашел, что он описан под этим именем очень давно ).

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