Как перевести разработку существующего приложения MVC3 на подход TDD?

Question

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

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

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

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

Answer 1

Я не знаю ни одной из существующих процедур, но могу выделить то, что я обычно делаю.

Мой подход к существующей системе заключается в том, чтобы сначала попытаться написать тесты, чтобы воспроизвести дефекты, а затем изменить код для их исправления. Я говорю «попытка», потому что не все воспроизводимо и экономически эффективно. Например, попытка написать тест, чтобы воспроизвести проблему, связанную с переходами CSS3 в очень специфической версии IE, может быть крутой, но неэффективным использованием вашего времени. Я обычно даю себе крайний срок для написания таких тестов. Единственным исключением могут быть функции, которые высоко ценятся или трудно тестируются вручную (например, API).

Для любых новых функций, которые вы добавляете, сначала напишите тест (как если бы тестируемый класс был API), убедитесь, что тест не пройден, и реализуйте функцию, чтобы выполнить тест. Повторение. Когда вы закончите с этой функцией, запустите что-то вроде PEX . Это будет часто выдвигать на первый план вещи, о которых Вы никогда не думали. Будьте разумны в отношении того, какие проблемы необходимо исправить.

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

Обратите особое внимание на болевые точки, поскольку они выделяют области, которые должны быть подвергнуты рефакторингу. Например, если у вас есть контроллер, который использует ObjectContext / IDbCommand / IDbConnection напрямую для доступа к данным, вы можете обнаружить, что вам требуется настроить базу данных и т. Д. Только для проверки бизнес-условий. Это мой намек на то, что мне нужен интерфейс к слою доступа к данным, чтобы я мог его смоделировать и смоделировать эти бизнес-условия в моем контроллере. То же самое касается доступа к реестру и т. Д.

Но будьте внимательны к тому, для чего вы пишете тесты. Значение TDD в какой-то момент уменьшается, и на самом деле написание этих тестов может стоить дороже, чем дать его кому-то в Индии для ручного тестирования.