Как отловить внутренний метод класса?

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

Изменить: На самом деле я новичок в моке. У меня есть много классов и методов классов для тестирования с использованием Moq. Многие классы являются внутренними, многие из них имеют внутренние методы, многие из них не имеют виртуальных методов. И не может изменить подпись на методах и классах. Может кто-нибудь, пожалуйста, дайте мне знать, как пройти тестирование этого сценария с помощью Moq. Или, пожалуйста, предложите мне другую структуру тестирования, с которой легко учиться и легко работать.

Ответ 1

Почему вы хотите издеваться над внутренним методом?

Если вы обнаружите необходимость издеваться над внутренним методом, скажем, чтобы обойти зависимость или взаимодействие, вы, возможно, должны рассмотреть редизайн класса.

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

Я не верю, что есть ясный путь к непубличной насмешке с Moq.

Но, если вам абсолютно необходимо, вы можете использовать TypeMock Isolator, чтобы издеваться над чем угодно.

Кроме того, просто так он не заблудится в Din: Томас связал хорошую статью о том, как использовать бесплатные MS Moles, чтобы издеваться над непубличными членами.

Издевательство над Unmockable: использование Microsoft Moles с Gallio

Ответ 2

Вы можете легко высмеять внутренние виртуальные методы, добавив следующее к вашему AssemblyInfo.cs:

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] // namespace in Moq
[assembly: InternalsVisibleTo("YourTestClass")]

Если ваша сборка сильно пронумерована, вам нужно будет включить открытый ключ для DynamicProxyGenAssembly2 (спасибо комментарию от @bvgheluwe; source: Moq руководство по быстрому старту):

[assembly:InternalsVisibleTo("DynamicProxyGenAssembly2,PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]

Я не понимаю, почему в принятом ответе говорится, что вы никогда не должны этого делать. Разве это не то, что вы делаете, когда используете метод инъекции "Извлечение и переопределение" (локальный метод factory), описанный Роем Ошеровым в Глава 3 Тестирование тестирования оборудования?

Ответ 3

Отметьте метод как internal *protected* (также виртуальный, конечно)

Ответ 4

Не с Moq.

Но вы можете использовать свободную структуру Moles от MS, чтобы делать такие вещи. Я писал об этом здесь: Издевательство над Unmockable: использование Microsoft Moles с Gallio. (это относится не только к Галлио, но и дает хорошее общее впечатление о том, что вы можете сделать с Moles...). Другой альтернативой будет Typemock...

НТН. Томас

Ответ 5

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

Если вы считаете, что необходимо изменить метод, чтобы сделать класс проверяемым, реорганизовать класс, чтобы сложная часть стала зависимой или иным образом подменялась параметром или подклассом.

Ответ 6

Если вам нужно проверить много кода, который вы не можете изменить, лучше начать с MS Moles или TypeMock с самого начала.

Свободные насмешливые фреймворки, такие как Moq, дают вам поддержку по интерфейсам и виртуальным методам. Не звучит так, как будто вы далеко продвинетесь с этим...

Томас