Refactor - UnitTest - Разработка трилеммы в устаревшем коде - PullRequest
Новая
       22

Refactor - UnitTest - Разработка трилеммы в устаревшем коде

4 голосов
/ 27 ноября 2011

Как вы решаете эту проблему, когда имеете дело с устаревшим кодом

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

С чего начать?Как вы атакуете проблему?

Ответы [ 2 ]

3 голосов
/ 27 ноября 2011

Курица и яйцо.

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

Если у вас еще нет тестов Integration, System и GUI, это будет хорошей причиной для их создания до того, как вы начнете создавать модульные тесты. После того, как они у вас есть, вы можете начать рефакторинг кода для создания достойных модульных тестов и при этом быть достаточно уверенным, что ваши всеобъемлющие тесты поймают ваши самые очевидные ошибки.

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

Об этом следует прочитать Эффективная работа с устаревшим кодом , автор Michael Feathers.

Заключение

Стратегия, которую я изложил, работает для самых разных изменений, Однако есть некоторые предостережения. Иногда единственный достойный перегиб точка, которую вы можете найти для набора классов, является системной границей. В некоторых приложениях граница системы может быть довольно широкой: включает в себя графический интерфейс, звонки в другие внешние библиотеки, базу данных, и т.д. В этих случаях лучший способ получить инвариант - это запустить писать то, что Стив Макконнелл называет «тестами на дым» против остальных система

0 голосов
/ 27 ноября 2011

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

...