Здравствуйте, Aggtaa, Вы писали:
L>>Вы сами выделили отдельный элемент функциональности, который вы хотите оттестировать — фильтрацию типов. Вот это и вынесите в отдельный метод и оттестируйте его. Сигнатура: IEnumerable<Type> -> IEnumerable<Type>.
A>Так?
A>A> private static IEnumerable<Type> GetAssemblyProviderTypes(IEnumerable<Type> types)
A> {
A> foreach (Type type in types)
A> if ((type.GetInterface(typeof(IActionProvider).FullName) != null)
A> && (type.GetConstructor(new Type[0]) != null))
A> yield return type;
A> }
A>
Или
return types.Where(IsValidType);
A>Для тестирования придется этот метод делать public или хотя бы internal. Вытаскивать с мясом наружу кусок логики неправильно, мне кажется. И ведь я хочу протестировать еще и загрузку. Типа "валидно написанные классы валидно загружаются, невалидно написанные и левые классы не загружаются".
Ну, как не крути, а необходимость тестировать все-таки вынуждает иначе подходить к проектированию. От этого не уйти.
A>Но это мелочи по сравнению с public логикой. Мне неинтересно тестировать маленький аспект работы кода в отдельных 3 строчках.
A>Мне нужно убедиться, что вся публичная функциональность этого кода ведет себя предсказуемо, повторяемо и правильно. В этом же смысл юниттестирования?
Это нормально. SRP.
A>>>И еще возник вопрос. Как быть, если само существование тестов уже влияет на поведение тестируемого кода?
L>>Просто вынесите код тестов в отдельную сборку.
A>Сборка с тестами все равно будет загружена в домен на момент выполнения теста.
Ну так только на момент выполнения теста.
