Использование Microsoft Fakes и VB.net для заглушки метода Get свойства в заглушенном классе

Я использовал строго Microsoft Fakes для модульного тестирования. (поэтому мне не нужен nUnit или другие примеры.) Я могу создать заглушку для класса, который, как я ранее считал, невозможен при условии, что классы должны реализовывать интерфейс для заглушки. Я считаю, что могу создать заглушку из-за использования инъекции зависимостей, хотя я не уверен... (если у кого-то есть дополнительная информация об этом, я был бы очень признателен.)

Хотя это само по себе может быть проблемой, я хотел бы увидеть пример с синтаксисом для Stub свойства Getter или Setter с VB.net и Microsoft Fakes. У Microsoft не так много сложных примеров использования подделок с VB.net (только C#), и это стоило мне нескольких часов попыток определить разницу, поскольку сам Vb.net также является для меня чем-то новым.

В частности, в этом примере у нас есть большой класс с именем Plan, который в данном конкретном случае имеет свойство Clusters типа ClusterCollection. Я хотел бы заглушить геттер Plan.Clusters, чтобы он возвращал самоопределяемую ClusterCollection. Это код, который я пытался написать для выполнения, и он не сработал...

    Dim cc As New ClusterCollection   
       'I would add elements to CC here.

    Dim myPlan As New StubPlan
    With myPlan
        .ClustersGet= _
            Function()
                Return cc
            End Function
    End With

На 99% уверен, что это не тот способ, но intellisense мне тоже не очень помогает. Помощь???


person a-1    schedule 11.10.2013    source источник


Ответы (1)


У меня есть опыт работы с C #, но я думаю, что могу ответить на ваши вопросы. Во-первых, подделки могут заглушить все, что можно реализовать или расширить.

Заглушки и прокладки работают, создавая общедоступное свойство типа Action или Func с правильными аргументами и типом возвращаемого значения, а также переопределяют методы для выполнения указанного делегата. Таким образом, вы можете передать любой соответствующий делегат в виде группы методов, лямбда-выражения или традиционного делегата.

Судя по документации, вы синтаксически правы. Как вы используете заглушку? Заглушки - это только один экземпляр. Если ваша цель состоит в том, чтобы переопределить ClustersGet в любом появившемся плане, а не в экземпляре, который, как вы знаете, будет использоваться, рассмотрите возможность использования прокладок или перепроектирования вашего метода для поддержки внедрения зависимостей, а именно передачи ему объекта Plan.

person Magus    schedule 14.10.2013
comment
Я намереваюсь, чтобы это был только этот экземпляр, который возвращает что-то, что я явно определяю. Это основная проблема, почему я использую прокладки в своем модульном тестировании, а не заглушки. Я мог бы заменить почти все свои прокладки заглушками, если бы лучше понимал, как передать делегата. Учитывая, что ни один из этих классов не реализует интерфейс, может ли это быть проблемой? Тем не менее, я могу создавать объекты-заглушки (как показано выше) и передавать их в конструкторы. - person a-1; 28.10.2013
comment
Заглушка просто наследует или реализует любой объект, на котором она основана, и объявляет свойства с делегатами для каждого метода. Не более того. Интерфейс имеет немного больше свободы, поскольку заглушка, конечно, может переопределять только виртуальные методы. Интерфейс ни в коей мере не требуется. - person Magus; 29.10.2013
comment
почему, когда я пробую этот синтаксис (как показано выше и MSDN), я могу получить доступ только к свойству Clusters, которое получает или устанавливает, и недоступны заглушки для получения или установки? Ни заглушенных методов... поскольку они не имеют добавленных параметров. На самом деле, это выглядит почти так же, как если бы это был обычный Plan... Как именно я узнаю, можно ли реализовать или расширить мой класс Plan? Я не могу понять, как я нахожусь в какой-то средней области, где я могу создавать заглушки, но на самом деле не использую их ни для чего, кроме экономии времени. - person a-1; 31.10.2013
comment
Если делегаты get и set не созданы, это означает, что они не являются членами непосредственного базового класса или не являются виртуальными. В .NET члены не являются виртуальными по умолчанию и поэтому не могут быть переопределены, если явно не установлены виртуальные с помощью ключевого слова virtual. - person Magus; 31.10.2013