Здравствуйте, Lloyd, Вы писали:

A>>"Все происходит" — это что? Я не хочу проверять реализаторов IActionProvider — для этого есть отдельные тесты. Мне бы убедиться, что все нужные типы загружаются и не загружаются лишние. Т.е. логику именно метода Load.
L>Вы сами выделили отдельный элемент функциональности, который вы хотите оттестировать — фильтрацию типов. Вот это и вынесите в отдельный метод и оттестируйте его. Сигнатура: IEnumerable<Type> -> IEnumerable<Type>.
Так?

        private static IEnumerable<Type> GetAssemblyProviderTypes(IEnumerable<Type> types)
        {
            foreach (Type type in types)
                if ((type.GetInterface(typeof(IActionProvider).FullName) != null)
                        && (type.GetConstructor(new Type[0]) != null))
                    yield return type;
        }

Для тестирования придется этот метод делать public или хотя бы internal. Вытаскивать с мясом наружу кусок логики неправильно, мне кажется. И ведь я хочу протестировать еще и загрузку. Типа "валидно написанные классы валидно загружаются, невалидно написанные и левые классы не загружаются".

Но это мелочи по сравнению с public логикой. Мне неинтересно тестировать маленький аспект работы кода в отдельных 3 строчках.
Мне нужно убедиться, что вся публичная функциональность этого кода ведет себя предсказуемо, повторяемо и правильно. В этом же смысл юниттестирования?

A>>И еще возник вопрос. Как быть, если само существование тестов уже влияет на поведение тестируемого кода?
L>Просто вынесите код тестов в отдельную сборку.
Сборка с тестами все равно будет загружена в домен на момент выполнения теста.