Как найти все модульные тесты, которые могут прямо или косвенно вызывать данный метод? (.сеть)

Visual Studio 2010 имеет именно эту функцию: http://blogs.msdn.com/b/phuene/archive/2009/12/07/test-impact-analysis-in-visual-studio-2010.aspx.

Поскольку вы используете nunit, вы также можете попробовать эту технику для запуска MSTest: http://msdn.microsoft.com/en-gb/magazine/cc163643.aspx#S4

В самом общем случае, когда вы используете делегаты, лямбда-выражения и т. д., у меня есть интуиция, что эта проблема эквивалентна проверке, завершится ли данная программа (Проблема остановки), поэтому я не надеялся найти разумный ответ.

Если ваша реальная цель состоит в том, чтобы иметь возможность быстро проверить, не сломалось ли что-то из-за вашего изменения, я бы порекомендовал:

• рефакторинг ваших тестов
• настройка инфраструктуры параллельной сборки с кластером машин сборки (проще, чем вы думаете, с помощью современных инструментов, таких как TeamCity)

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

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

Однако это можно вычислить с помощью инструмента тестового покрытия. Для каждого отдельного теста запустите этот тест (мы предполагаем, что он прошел) и соберите данные о покрытии тестами. Теперь у нас есть много пар (t_i,c_i) для «тест i имеет покрытие c».

При изменении базы кода можно обращаться к наборам покрытия тестовых данных. Простая проверка: если для любого (t_i,c_i), если c_i упоминает файл F, а F изменился, нужно снова запустить t_i. Учитывая данные о тестовом покрытии практически в любом представлении, это легко обнаружить абстрактно. Учитывая, что большинство инструментов тестового покрытия конкретно не сообщают вам, как они хранят данные тестового покрытия, это сложнее, чем кажется на практике.

На самом деле, в идеале вы хотите, чтобы если c_i упоминает какой-либо программный элемент F, и этот программный элемент изменился, вам нужно снова запустить t_i.

Наши инструменты SD Test Coverage предоставляют эту возможность для Java и C# на уровне методов. Вам нужно настроить некоторые сценарии, чтобы связать фактический тест, независимо от того, как вы его упаковали, с собранными векторами тестового покрытия. С практической точки зрения это довольно просто.

Вы можете использовать «Просмотр иерархии вызовов» VS2010 или ReSharpers «ReSharper -> Проверка -> Входящие вызовы». Вы даже можете экспортировать результат из ReSharper.
Если вы хотите использовать автоматизацию для достижения своей цели, т.е. потому что это не одноразовая вещь, а то, что вы хотите интегрировать в свой процесс сборки, я предлагаю вам построить ваше собственное решение. Вы можете использовать Reflection или Mono.Cecil на сборках и самостоятельно пройти иерархию вызовов. Однако это может занять довольно много времени, поскольку вам потребуется создать полное дерево иерархии вызовов для всех ваших сборок. Другой возможностью было бы создание плагина Visual Studio или ReSharper, чтобы вы могли получить доступ к объектной модели, которую они создают из вашего исходного кода. ваша цель с помощью автоматизации и написания собственного решения будет интересной, но сложной и, возможно, трудоемкой, как при разработке, так и при ее запуске.