Нужно ли проводить тестирование модулей и интеграции, если вы уже проводите функциональное тестирование?

Ответ 1

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

Я бы использовал unit test новую функциональность, как я ее написал, по трем причинам:

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

(Это включает исправления ошибок, как это было предложено Epaga.)

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

Ответ 2

Большинство людей не знают, что такое автоматические модульные тесты:

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

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

Ответ 3

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

Ответ 4

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

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

И я должен согласиться с Джоном Скитом (как я не мог?) рекомендовать "" Эффективно работать с устаревшим кодом", это действительно было полезным снятием/чтением.

Ответ 5

Как это бывает, я прочитал статью прошлой ночью по этому вопросу. Авторы сравнивают проекты в четырех группах в Microsoft и IBM, контрастируя, в ретроспективе, с проектами, которые использовали как модульное тестирование, так и функциональное тестирование и проекты, которые использовали только функциональное тестирование. Процитировать авторов:

"Результаты тематических исследований указать, что предварительный выпуск плотность дефектов четырех изделий уменьшилось от 40% до 90% относительно к аналогичным проектам, которые не использовали практика TDD. Субъективно команды испытали увеличение на 15-35% в начальное время разработки после принимая TDD."

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

Ответ 6

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

Ответ 7

Одно приложение, которое я купил, чтобы проконсультироваться по FAT (тест), состоял из оператора переключения 21 000 строк. Большинство единиц функциональности были от нескольких десятков до нескольких сотен строк в case case. Приложение было построено в нескольких вариантах, поэтому было много разделов #ifdef коммутатора.

Он не был предназначен для модульного тестирования - он вообще не учитывался.

(Он был спроектирован в том смысле, что существует определенная, простая в понимании архитектура - malloc a struct, отправляет основной цикл пользовательскому сообщению с указателем на struct как lparam, а затем освобождает его, когда сообщение обрабатывается. Но форма не соответствовала функции, которая является центральным принципом хорошего дизайна.)

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

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

Ответ 8

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

Если вы уверены, что ваш продукт будет работать, и у вас нет вопросов об этом, есть еще один вопрос, который стоит задать: почему у меня нет вопросов?

--- Майкл Б.

Ответ 9

Единичное тестирование действительно является дополнительной работой, но оно окупается в долгосрочной перспективе. Вот преимущества перед тестированием интеграции:

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

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

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

С большой устаревшей кодовой базой, устаревшей в смысле не тестируемой единицы, я бы рекомендуем ограничивать модульные тесты новыми функциями, добавленными в код, как  модульные тесты могут быть сложными. В этой связи,  Я могу только второй (третий?) Рекомендацию "Рабочего Эффективно с устаревшим кодом ", чтобы помочь провести модульное тестирование в существующем кодовая.