Зачем использовать Mocking Framework? - PullRequest
Новая
       41

Зачем использовать Mocking Framework?

5 голосов
/ 04 июля 2011

В настоящее время мы следуем модели DI, используя Autofac в качестве контейнера IoC.

Недавно мы начали изучать макеты для моделирования, такие как MOQ и Rhino Mocks.Однако мы не можем оправдать их использование простым созданием классов реализации Mock для каждого из наших интерфейсов.

Зачем это делать: 

var mock = new Mock<IFoo>();
mock.Setup(foo => foo.DoSomething("ping")).Returns(true);

Вместо этого: 

class FooMock : IFoo {
  bool DoSomething(string input) {
    return input == "ping";
  }
}
mock = new FooMock();

Последний является более многословным, но кажется более гибким и подходящим для сложных макетов.

Ответы [ 3 ]

12 голосов
/ 04 июля 2011

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

Существует каноническая статья Мартина Фаулера, в которой обсуждается тот факт, что издевательства не являются заглушками , и я взял из него следующий абзац:

Ключевое отличие здесь в том, как мы убедитесь, что заказ сделал правильно вещь во взаимодействии с склад. С государственной проверкой мы сделать это, утверждая против состояние склада. Издевается над поведением проверка, где мы вместо этого проверяем чтобы убедиться, что заказ сделан правильно звонки на склад.

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

Конечно, вы все еще могли бы писать свои собственные кейсы, но использование фреймворка сэкономит вам много времени, даст больше читаемых тестов и сэкономит на ошибках в тестах.

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

Чтобы продемонстрировать с помощью некоторого кода, представьте этот метод PrintOrders (извините за глупый пример): 

public void PrintForeignOrders(List<Orders> orders)
{
    foreach(var order in orders)
    {
        if (order.IsForeign)
        {
            printer.PrintOrder(order.Number, order.Name);
        }
    }
}

Возможно, вы захотите проверить хотя бы:

  • Когда список пуст, ничего не печатается
  • При наличии иностранного заказа печатается
  • При наличии двух заказов печатаются оба (с правильным номером и названием)

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

9 голосов
/ 04 июля 2011

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

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

7 голосов
/ 04 июля 2011

Однако мы не можем оправдать их использование над созданием макета классы реализации для каждого из наших интерфейсы.

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

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

...