Рефакторинг для тестируемости в существующей системе

Я присоединился к команде, которая работает над продуктом. Этот продукт существует около 5 лет и использует ASP.NET WebForms. Его оригинальная архитектура со временем исчезла, и во всем решении все стало относительно неорганизованным. Это ни в коем случае не ужасно, но определенно может использовать некоторую работу; Вы все знаете, что я имею в виду.

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

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

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

21.08.2008 15:34:46
5 ОТВЕТОВ
РЕШЕНИЕ

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

Я настоятельно рекомендую получить копию книги Майкла Фезера « Эффективная работа с устаревшим кодом» (под «Устаревшим кодом» подразумевается любая система, которая не охвачена модульными тестами). Здесь полно хороших идей о том, как сломать те связи и зависимости, о которых вы говорите, безопасным способом, который не рискует привести к ошибкам регрессии.

Удачи в программе рефакторинга; по моему опыту, это приятный и катарсический процесс, из которого вы можете многому научиться.

5
23.08.2008 10:25:29

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

2
21.08.2008 15:37:54

Просто выпишу вторую рекомендацию по эффективной работе с Legacy Code, отличную книгу, которая действительно открыла мне глаза на тот факт, что практически любой старый / дрянной / непроверяемый код может быть подвергнут сомнению!

0
23.08.2008 11:43:53

Я также хотел бы добавить предложение посетить веб-сайт Рефакторинга Мартина Фаулера. Он буквально написал книгу об этом материале.

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

Модульное тестирование ASP.Net может быть сложным, но существует множество платформ, облегчающих его выполнение. ASP.Net MVC и WCSF, чтобы назвать несколько.

1
17.09.2008 04:04:27

Полностью согласен с ответом Яна Нельсона . Кроме того, я бы начал получать некоторые «высокоуровневые» тесты (функциональные или компонентные тесты), чтобы сохранить поведение с точки зрения пользователя. Этот момент может быть самой важной проблемой для вашего премьер-министра.

0
23.05.2017 11:55:45