Лучшая стратегия для подготовки кода для модульного тестирования

Question

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

Существуют ли другие предложения или рекомендации по использованию устаревшего решения и приведению его в форму для подготовки к покрытию кода и модульному тестированию?

Answer 1

Выезд Эффективная работа с устаревшим кодом .

Answer 2

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

Действительно, просто начни это делать. Вы не будете иметь огромное освещение в унаследованном приложении в одночасье. Начните с нажатия на код, который более подвержен поломкам, и начните разветвляться. Убедитесь, что любая новая разработка в коде также имеет более высокий охват кода.

Помните, что мантра TDD - «красный / зеленый / рефакторинг», и вы можете захотеть изучить инструменты рефакторинга, чтобы помочь выполнить некоторые утомительные задачи, которые сопровождают ее. JetBrain ReSharper популярен, и мой личный выбор.

Answer 3

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

Answer 4

Начните с создания тестов. Рефакторинг кода по мере необходимости для поддержки тестов.

Answer 5

Вам нужно протестировать свой код, чтобы убедиться, что вы ничего не сломаете при рефакторинге.

Answer 6

Попробуйте начать читать о TDD.

http://www.codeproject.com/KB/dotnet/tdd_in_dotnet.aspx

Answer 7

Это общие рекомендации, которые я считаю полезными для модульного тестирования:

1) Определение пограничных объектов (Win / WebForms, CustomControls и т. Д.).

2) Идентифицировать объекты управления (объекты бизнес-уровня)

3) Записывать модульные тесты только для открытых объектов управления методами, вызываемыми граничными объектами. Таким образом, вы будете уверены, что освещаете основные функциональные аспекты своего приложения.

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

Возможность этого очевидным образом зависит от конкретного случая.