Родинки и внутренние классы

Question

В настоящее время мы используем Moles для тестирования некоторого кода, который взаимодействует со сторонней библиотекой.Библиотека не была настроена для тестирования очень хорошо (отсюда необходимость родинок), и проблема, с которой я сталкиваюсь, заключается в том, что они публично представляют только один абстрактный класс.Конкретные реализации являются внутренними для сторонней библиотеки.

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

В документации по родинкам способ раскрытия внутренних компонентов заключается в добавлении атрибута InternalsVisibleTo в файл AssemblyInfo.cs.Однако, это для того, чтобы показать мои внутренние компоненты сборки для использования родинок, так как это сторонние библиотеки с уже созданными сборками, и я не знаю, как сделать так, чтобы эти внутренние компоненты были видимыми, чтобы кроты могли использовать их.

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

Answer 1

Подход, который я использовал очень успешно, состоит в том, чтобы использовать свои собственные прокси-классы для немоделируемых сторонних типов. Например. Я хочу взять зависимость от типа ThirdParty.Foo, который запечатан / статический / не имеет интерфейса / и т.д. Вместо этого я создаю библиотеку с именем ThirdParty.Proxies и добавляю конкретный тип Foo и интерфейс IFoo к этой новой библиотеке. Интерфейс IFoo предоставляет члены, эквивалентные всем тем, которые мне требуются от базового типа ThirdParty.Foo, а конкретный тип ThirdParty.Proxies.Foo реализует эти члены, не делая ничего, кроме переадресации вызовов методов в базовую стороннюю библиотеку. ThirdParty.Proxies исключен из модульного тестирования и покрытия кода. В моей потребительской сборке я беру зависимость только от ThirdParty.Proxies и, в частности, я беру зависимость только от IFoo. Таким образом, я могу легко смоделировать эту зависимость и достичь 100% покрытия кода для моей потребляющей сборки.

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