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

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 тестово покритие предоставят тази възможност за Java и C# на ниво методи. Трябва да настроите някои скриптове, за да свържете действителния тест, както и да сте го пакетирали, със събраните вектори на тестово покритие. От практическа гледна точка това обикновено е доста лесно.

Можете да използвате „Преглед на йерархията на повикванията“ на VS2010 или ReSharpers „ReSharper -> Проверка -> Входящи повиквания“. Можете дори да експортирате резултата от ReSharper.
Ако искате да използвате автоматизация, за да постигнете целта си, т.е. защото това не е еднократно нещо, а нещо, което искате да интегрирате в процеса на изграждане, предлагам да изградите вашето собствено решение. Можете да използвате Reflection или Mono.Cecil върху сглобките и да преминете сами в йерархията на повикванията. Това обаче може да отнеме доста време, тъй като ще трябва да създадете цялостно йерархично дърво на повикванията върху всичките си сборки. Друга възможност би била да създадете приставка за Visual Studio или ReSharper, така че да имате достъп до обектния модел, който те създават от вашия изходен код.
По принцип това, което казвам е: не знам за съществуващ в момента метод за постигане целта ви чрез автоматизация и писане на собствено решение ще бъде забавна, но трудна и евентуално отнемаща време, както при разработването, така и при изпълнението му.