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

Question

В настоящее время я читаю книгу (Pro ASP.Net Framework).

В этой книге автор предлагает использовать Moq framework , чтобы помочь сделать TDD.

[Test]
public void List_Presents_Correct_Page_Of_Products()
{
    IProductsRepository repository = MockProductsRepository(
        new Product { Name = "P1" }, new Product { Name = "P2" },
        new Product { Name = "P3" }, new Product { Name = "P4" },
        new Product { Name = "P5" }
    );

    ProductsController controller = new ProductsController(repository);
    ...
}


static IProductsRepository MockProductsRepository(params Product[] prods)
{
    // Generate an implementor of IProductsRepository at runtime using Moq
    var mockProductsRepos = new Moq.Mock<IProductsRepository>();
    mockProductsRepos.Setup(x => x.Products).Returns(prods.AsQueryable());
    return mockProductsRepos.Object;
}

На уровне модели мы определили FakeRepository и SqlRepository.

Дело в том, что я не вижу преимущества использования этого moq framework. Почему мы не используем только наш FakeRepository? Или очистить наш FakeRepository и добавить на него поддельный продукт?

Сначала я подумал, что среда moq предназначена для генерации поддельных данных, поэтому вам не нужно, если у вас есть, например, 100 поддельных объектов для генерации.

Что мне не хватает?

Answer 1

Некоторые преимущества макетов макетов по сравнению с ручными катками:

• Поведенческое поведение ближе к тестовому коду, потому что это в тестовом коде. Это облегчает понимание тестов, не обращая внимания на другой код.
• Вам не нужно создавать еще один фиктивный класс (или еще хуже: добавьте логику к существующему) только потому, что вам нужно немного другое поведение.
• В итоге вы пишете меньше стандартного шаблона, потому что вам нужно только настроить методы, которые вы хотите смоделировать, в то время как с ручными вы должны реализовать весь интерфейс.

Некоторые недостатки:

• Вы должны изучить основы, в то время как каждый может писать макеты вручную.
• Это еще одна зависимость, которую вы добавляете в свой проект.

(Это то, о чем я могу думать прямо сейчас. Не стесняйтесь редактировать и добавлять больше.)

Answer 2

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

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

Аналогичный вопрос доступен здесь .

Answer 3

Возможно, вы захотите прочитать это Ручное издевательство: сопротивление вторжению точек и скобок

Answer 4

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

Есть больше фреймворков, чем просто Moq; Есть RhinoMocks и TypeMock (мой личный фаворит, хотя это стоит денег, если это не проект с открытым исходным кодом), чтобы назвать несколько.

Answer 5

Мы используем его для создания поддельного сервера в среде клиент / сервер.

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