Самый простой и быстрый способ вырвать все зависимости из класса - PullRequest
11 голосов
/ 30 июня 2010

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

В большинстве случаев статические вызовы обрабатываются либо путем переноса статической зависимости, либо если ее одноэлементный шаблон (или аналогичный) в форме StaticClass.Current.MethodCall (), передающий эту зависимость через интерфейс, вместо этого идет в конструктор.

В большинстве случаев использование ключевого слова new в конструкторе просто заменяется передачей этого интерфейса в конструкторе.

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

Я всегда использую инструменты рефакторинга Resharpers, чтобы помочь мне во всех этих прорывах, однако большинство вещей все еще являются ручным трудом (который может быть автоматизирован), а для некоторых устаревших классов и методов это может быть очень и очень утомительным процессом. Существуют ли другие плагины и / или инструменты для рефакторинга, которые могут помочь мне в этом процессе? Существует ли инструмент рефакторинга «вырвать все зависимости из этого класса в один клик»? =)

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

ДОБАВЛЕНО:

В ответ на ответы ниже: даже если вы можете не захотеть разбить все на части (разрыв всего на один клик может вызвать больше проблем, чем помогает), вы все равно сможете просто разбить зависимости 1 методов или 1-2 зависимости легко, будет иметь большое значение.

Кроме того, в рефакторинге кода есть мера «попробуй и посмотри, что происходит, просто чтобы узнать, как все сочетается», и общий разрыв в один клик поможет обработать тонны, даже если этот код не проверять в ... 1019 *

Ответы [ 2 ]

3 голосов
/ 30 июня 2010

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

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

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

Удачи.

1 голос
/ 30 июня 2010

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

...