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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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