Является ли создание поддельного хранилища для прокси-класса поддельного веб-сервиса хорошей идеей?

Question

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

На стороне клиента , однако, допустим, у меня есть веб-приложение на основе MVC, которое вызывает этот веб-сервис через прокси-сервер службы. Если я хочу, чтобы модуль тестировал логику в приложении MVC и подавал ее данные, которые являются репрезентативными для возврата службы, как я могу подделать ссылку на прокси? Мои мысли, таким образом, хотя я не чувствую себя 100% уверены в этом и интересно, если я мог бы не быть более простое решение:

Я могу настроить прокси-интерфейс (назовем его IProxy), а затем установите (скажем, прокси и FakeProxy) и вставляйте одно, соответствующее выполняемой ситуации (FakeProxy при выполнении модульных тестов и прокси для реального производственного приложения). Чтобы генерировать некоторые выборочные данные для модульных тестов без фактических вызовов службы, следует ли я реализовать поддельный репозиторий (возможно, тот же самый, который используется в сценарии сервера выше) в Fake Proxy? Я не уверен, как лучше настроить поддельный класс прокси, чтобы помочь с тестированием моего кода на стороне клиента.

Update:

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

public class FakeCustomerProxy : ICustomerProxy 
{ 
    private List<Customer> Customers; 

    public FakeProxy() 
    { 
     Customers = new List<Customer>(); 

     Customers.Add(new Customer { Id = 1, Name = "Smith, John" }); 
     Customers.Add(new Customer { Id = 2, Name = "Johnson, Al" }); 
     Customers.Add(new Customer { Id = 3, Name = "Thomas, William" }); 
    } 

    public Customer GetById(int customerId) 
    { 
     return Customers.Where(c => c.Id == customerId).FirstOrDefault(); 
    } 
} 

В GetByID() метода, вместо того, чтобы позвонить в Интернет службы для получения желаемой информации о клиенте, просто возвращает ее из списка жестко запрограммированных клиентов, вложенных в этот класс. Это действительно похоже на то, что я могу настроить для фальшивого репозитория (у меня может быть очень похожий код, настроенный на стороне сервера, чтобы помочь с тестированием логики обслуживания), поэтому мне было любопытно, стоит ли мне рассматривать размещение этих жестко настроенных клиентов ссылки в выделенный поддельный класс репозитория, который будет использоваться в нескольких местах. Могу я подумать, что дизайн этого Fake Proxy совершенно не прав?

Answer 1

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

На самом деле, только один поддельный (прокси-сервер или репозиторий) будет достаточно вообще.

Я предлагаю вам посмотреть на насмешливые рамки (например, Moq или Rhino Mock).
Использование mocks, вам даже не понадобится реализация FakeProxy. В каждом тесте вы можете легко настроить отдельную смешную реализацию IProxy, которая будет действовать именно так, как вам нужно: вернуть предопределенные данные, сделать исключения, проверить пройденные параметры и т. Д.

Итак, вам не нужно будет реализовывать 1 или 2 поддельных классы для тестирования.

UPDATE:
Итак, я вижу 2 варианта здесь:

1. Для того, не многоразовые данные простой тест, который является специфичным для каждого конкретного теста. Возможно, вам потребуется настроить что-то вроде мини-репозитория (около 1-3 позиций) на каждый тест или группу тестов;

2. Чтобы иметь достаточно большой многоразовый поддельный репозиторий, который является общим для серверного кода &. Скорее всего, вам понадобится поддержка некоторых дополнительных жгутов для использования этого поддельного репозитория в тестах на стороне клиента и в тестах на стороне сервера. Например. вам понадобится дополнительно FakeProxy для проверки клиентского кода.

Вы должны рассмотреть эти варианты и выбрать то, что более подходит в вашем случае.

На мой взгляд, вариант 1 подходит для модульных испытаний, но вариант 2 может быть полезен для интеграционных тестов.

Answer 2

Нет, вы не должны повторять свою реализацию соединения репозитория-прокси в тестах. Рано или поздно будет существовать какая-то бизнес-логика между прокси-фасадом и репозиторием, и вам придется реализовать его дважды - на стороне сервера и на стороне клиента в FakeProxy.

Итак, ваш фиктивный экземпляр FakeProxy должен просто вернуть необработанные данные из вызовов.

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