Как найти код, который вызывается только тестами

Иногда я смотрю на какой-то код, ищу использование метода (используя resharper) и обнаруживаю, что он вызывается только тестами. Так что это фактически избыточно, и я могу удалить его и методы, которые его вызывают.

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

У меня есть полная версия resharper, а также пробная версия NDepend, но я не знаю, как использовать любую из них, чтобы получить желаемый результат (без оплаты). Я подозреваю, что это возможно с полной версией NDepend, но есть ли другие инструменты, о которых люди знают?

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

Я начал щедрость, потому что я уверен, что кто-то еще должен был решить эту проблему раньше!


person Jonny Cundall    schedule 21.09.2010    source источник
comment
Часть этого тестового кода, вероятно, является издевательством, заглушками и т. Д.   -  person CaffGeek    schedule 21.09.2010
comment
@Chad все макеты, заглушки и т. Д. В моих тестовых проектах. В этом вопросе меня больше беспокоит производственный код.   -  person Jonny Cundall    schedule 21.09.2010


Ответы (3)


Ручной поиск с помощью NDepend должен работать с файлом Dependency Matrix. Там вы можете увидеть, какие методы используются только сборками модульного тестирования.

Я не уверен, что вы можете писать собственные запросы CQL с пробной версией. Но с Pro-версией вы можете использовать такой запрос:

SELECT METHODS WHERE IsUsedBy "ASSEMBLY:NAME_OF_THE_UNIT_TEST_ASSEMBLY" 
AND !(IsUsedBy "ASSEMBLY:NAME_OF_ANOTHER_ASSEMBLY" OR IsUsedBy "ASSEMBLY:ANOTHER_NAME")

Чтобы это работало, вам нужно создать проект NDepend, который знает все ваши сборки.

Для NAME_OF_THE_UNIT_TEST_ASSEMBLY вы должны вставить свою сборку модульного теста, а во второй части вы должны указать свои сборки производственного кода с помощью IsUsedBy и разделить с помощью OR.

person Noffls    schedule 27.09.2010
comment
Насколько я вижу, мне нужна полная версия, чтобы иметь возможность запускать пользовательские запросы. Я собираюсь создать собственное правило FxCop в соответствии с вашим запросом (хотя для FxCop это намного сложнее ..) - person Jonny Cundall; 30.09.2010

Нетехническим подходом было бы временное удаление вашего тестового проекта из вашего решения, а затем использование анализа кода Visual Studio (или FxCop) для обнаружения любых методов, которые не вызываются ничем другим.

person Iain Hoult    schedule 29.09.2010
comment
Проблема с использованием FxCop заключается в том, что он игнорирует общедоступные методы при поиске мертвого кода, и я знаю, что многие вещи, которые я пытаюсь найти здесь, являются общедоступными методами. - person Jonny Cundall; 29.09.2010

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

person Alex Paven    schedule 21.09.2010
comment
Я изучил это, и похоже, что мне, вероятно, придется получить платную версию, чтобы иметь возможность добавлять свои собственные запросы. - person Jonny Cundall; 22.09.2010