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

Question

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

Клиентский продукт - это то, что я хочу для модульного тестирования, но он содержит более 1,2 миллиона строк кода на C # и очень старыйтовар.Он не был разработан с учетом модульного тестирования, и ведущие разработчики этого продукта, как правило, выступают против модульного тестирования, главным образом из-за рисков и опасностей, связанных с вознаграждением, а также из-за того, что потребуется редизайн, чтобы уменьшить количество насмешек, которые необходимо выполнить.,Модернизация этих базовых низкоуровневых клиентских библиотек и объектов также затрагивает их.

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

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

Answer 1

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

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

Answer 2

Мне показалось, что от Michael Feathers эффективно работает с устаревшим кодом , полезное при изучении этой темы.

Answer 3

Мой опыт:

1. Реализация способа для системных (сквозных) тестов
2. Когда вы добавляете новые функциональные возможности, пишите системные тесты и проектируйте новые функциональные возможности с помощью модульных тестов
3. Когда вы меняете существующую функциональность, заранее пишите системные тесты
4. НЕ пытайтесь переписать существующие модули для тестирования их с помощью модульных тестов

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

Answer 4

Я с вашими ведущими разработчиками. Это 1,2 миллиона строк кода, что означает, что существует много места для ошибок при тестировании и перепроектировании. Он не предназначен для UT, поэтому, вероятно, потребуется перезаписать код, чтобы его можно было протестировать. Я уверен, что модульное тестирование будет очень много времени. Кроме того, это старый продукт, который, вероятно, означает, что многие ошибки уже найдены и исправлены. Если это не сломано, не исправляйте его. Не лучше ли перейти к более интересным аспектам проекта, чем тестирование и рефакторинг старого кода?

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