Результаты метода имитации

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

Rhino Mocks, Typemock и Moq - хорошие варианты для этого.

Сообщение Стивена Вальтера по использованию Rhino Mocks мне очень помог, когда я впервые начал играть с Rhino Mocks.

Насколько мне известно, вы должны создать интерфейс или базовый абстрактный класс для объекта Helper. Затем с помощью Rhino Mocks вы можете вернуть желаемое значение.

В качестве альтернативы вы можете добавить перегрузку для LoadData, которая принимает в качестве параметров данные, которые вы обычно извлекаете из объекта Helper. Это может быть даже проще.

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

Вам нужно будет провести некоторый рефакторинг, чтобы иметь возможность внедрить фиктивный объект с помощью фиктивного метода GetSomeData ().

В этой упрощенной версии вашего кода сложно дать вам прямой ответ. У вас есть несколько вариантов:

• Создайте интерфейс для класса Helper и предоставьте клиенту возможность внедрить реализацию Helper в класс MyClass. Но если Helper - это просто служебный класс, в этом нет особого смысла.
• Создайте в MyClass защищенный метод с именем getSomeData и сделайте так, чтобы он вызывал только Helper.LoadSomeData. Затем замените вызов Helper.LoadSomeData в LoadData на getSomeData. Теперь вы можете имитировать метод getSomeData, чтобы вернуть фиктивное значение.

Остерегайтесь простого создания интерфейса для класса Helper. и введите его с помощью метода. Это может раскрыть детали реализации. Почему клиент должен предоставлять реализацию класса полезность для вызова простой операции? Это повысит сложность клиентов MyClass.

Я бы попробовал что-то вроде этого:

public class MyClass(){
  public void LoadData(IHelper helper){
    SomeProperty = helper.GetSomeData();
 }

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

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

public class MyClass()
{
    private IHelper _helper;

    public MyClass()
    {
        //Default constructor normal code would use.
        this._helper = new Helper();
    }

    public MyClass(IHelper helper)
    {
        if (helper == null)
        {
            throw new NullException(); //I forget the exact name but you get my drift ;)
        }
        this._helper = helper;
    }

    public void LoadData()
    {
        SomeProperty = this._helper.GetSomeData();
    }
    public object SomeProperty {get;set;}
}

Теперь ваш класс поддерживает так называемую инъекцию зависимостей. Это позволяет вам внедрить реализацию вспомогательного класса и гарантирует, что ваш класс будет зависеть только от интерфейса. Когда вы насмехаетесь над этим, знайте, что вы просто создаете макет, который использует интерфейс IHelper, и передаете его конструктору, и ваш класс будет использовать его, как если бы это был настоящий класс Helper.

Теперь, если вы застряли в использовании класса Helper в качестве статического класса, я бы посоветовал вам использовать шаблон прокси / адаптера и обернуть статический класс другим классом, поддерживающим интерфейс IHelper (который вам также потребуется создать).

Если в какой-то момент вы захотите сделать еще один шаг вперед, вы можете полностью удалить реализацию Helper по умолчанию из измененного класса и использовать контейнеры IoC (Inversion of Control). Если это ново для вас, я бы рекомендовал сначала сосредоточиться на основных принципах, почему все эти дополнительные хлопоты того стоят (это ИМХО).

Ваши модульные тесты будут выглядеть примерно так:

public Amazing_Mocking_Test()
{
    //Mock object setup
    MockObject mockery = new MockObject();
    IHelper myMock = (IHelper)mockery.createMockObject<IHelper>();
    mockery.On(myMock).Expect("GetSomeData").WithNoArguments().Return(Anything);

    //The actual test
    MyClass testClass = new MyClass(myMock);
    testClass.LoadData();

    //Ensure the mock had all of it's expectations met.
    mockery.VerifyExpectations();
}

Не стесняйтесь комментировать, если у вас есть какие-либо вопросы. (Кстати, я понятия не имею, работает ли весь этот код, я просто набрал его в своем браузере, в основном я иллюстрирую концепции).

Возможно, вы захотите изучить Typemock Isolator, который может «подделывать» вызовы методов, не заставляя вас реорганизовывать ваш код. Я разработчик в этой компании, но решение является жизнеспособным, если вы не хотите изменять свой дизайн (или вынуждены не менять его для проверки). это на www.Typemock.com

Рой блог: ISerializable.com