Как написать метод Internal mockable

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

есть ли способ иметь члена, над которым можно издеваться, а не на публике?


person kay.one    schedule 24.06.2010    source источник


Ответы (2)


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

Ну, один из вариантов заключается в том, что вы можете реализовать интерфейс internal и использовать [assembly:InternalsVisibleToAttribute], чтобы сделать внутренние типы доступными для ваших модульных тестов.

[assembly:InternalsVisibleTo("MyUnitTestAssembly")]

internal interface ISomeInterfaceForMocking { ... }

public class MyMockableType : ISomeInterfaceForMocking { ... }
person LBushkin    schedule 24.06.2010
comment
Это работает, но в этом случае все члены будут внутренними, есть ли способ получить больший контроль над этим? - person kay.one; 25.06.2010
comment
@Keivan - что именно вы подразумеваете под большим контролем? Ваши единственные другие варианты - сделать членов internal protected, что также позволит производным классам получать к ним доступ. - person LBushkin; 25.06.2010

Является http://code.google.com/p/moq/wiki/QuickStart#miscellaneous (см. раздел «Разное») любое использование (т. е. синтаксис для имитации protected материала)?

Интернет-провайдер говорит, что в интерфейсе не должно быть волшебных вещей, которые интересуют только некоторых людей. Кроме того, не рассматривали ли вы возможность использовать один метод virtual, а не целый интерфейс и/или базовый интерфейс для бита, который можно смоделировать? Или просто иметь для этого определенный интерфейс. Помните, что если сложно смоделировать или протестировать, обычно в вашем коде есть что-то, что можно улучшить (в отличие от поиска технических приемов для прыжков с обручей и/или перехода к чрезмерно мощным фреймворкам для имитации).

Кроме того, держу пари, что если вы опубликуете урезанную версию своего теста, кто-нибудь сможет правильно его отрефакторить, и мы все чему-нибудь научимся.

person Ruben Bartelink    schedule 25.06.2010