Разница синтаксиса между использованием Mock и Fake [duplicate]

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

Я удивлен, что этот вопрос существует так долго, и никто пока не получил ответа, основанного на «Искусстве модульного тестирования» Роя Ошерова .

In «3.1 Представление заглушек» определяет заглушку как:

Штук - это контролируемая замена существующей зависимости (или соавтора) в системе.

И определяет разницу между заглушками и mocks как:

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

Подделка - это просто имя, используемое для оба заглушки и издевки. Например, когда вам не нужно различать окурки и издевки.

Способ, которым Osherove проводит различие между окурками и mocks, означает, что любой класс, используемый в качестве подделки для тестирования, может быть как заглушкой, так и макетом , Что именно для конкретного теста полностью зависит от того, как вы пишете проверки в своем тесте.

• Когда ваш тест проверяет значения в тестируемом классе или фактически где-либо, кроме подделки, подделка использовалась в качестве заглушки. Он просто предоставил значения для тестируемого класса, либо непосредственно через значения, возвращаемые вызовами, либо косвенно, вызывая побочные эффекты (в некотором состоянии) в результате вызовов на нем.
• Когда ваш тест проверяет значения подделки, он использовался как макет.

Пример теста, в котором класс FakeX используется как заглушка:

const pleaseReturn5 = 5;
var fake = new FakeX(pleaseReturn5);
var cut = new ClassUnderTest(fake);

cut.SquareIt;

Assert.AreEqual(25, cut.SomeProperty);

fake используется как заглушка, потому что Assert вообще не использует fake.

Пример теста, в котором тестовый класс X используется как макет:

const pleaseReturn5 = 5;
var fake = new FakeX(pleaseReturn5);
var cut = new ClassUnderTest(fake);

cut.SquareIt;

Assert.AreEqual(25, fake.SomeProperty);

В этом случае Assert проверяет значение на fake, делая этот фальшивый макет.

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

Я согласен с тем, что

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

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

Я понимаю, что написание утверждений против подделки является обычной практикой, особенно когда вы являетесь подкатегоризированным типом подписчика TDD. Я думаю, что я твердо отношусь к Мартину Фаулеру в классическом лагере (см. «Маки не являются записями» Мартина Фаулера ) и, подобно Osherove, избегают тестирования на взаимодействие (что может быть сделано только путем утверждения против подделки), поскольку насколько это возможно.

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

Stub - объект, который предоставляет предопределенные ответы на вызовы методов.

Mock - объект, на который вы устанавливаете ожидания.

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

Test Double - это общий термин для заглушек, издевок и подделок. Но в неофициальном плане вы часто слышите, как люди просто называют их издевательствами.

Чтобы проиллюстрировать использование окурков и макетов, я хотел бы также привести пример на основе « Art of Unit Testing » Роя Ошерова.

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

логику, которую мы хотели бы протестировать внутри LogAnalyzer:

if(fileName.Length<8)
{
 try
  {
    service.LogError("Filename too short:" + fileName);
  }
 catch (Exception e)
  {
    email.SendEmail("a","subject",e.Message);
  }
}

Как вы проверяете, правильно ли LogAnalyzer вызывает службу электронной почты, когда веб-служба выдает исключение? Вот вопросы, с которыми мы сталкиваемся:

• Как мы можем заменить веб-службу?
• Как мы можем имитировать исключение из веб-службы, чтобы мы могли протестировать вызов службы электронной почты?
• Как мы узнаем, что служба электронной почты была вызвана правильно или вообще?

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

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

[TestFixture]
public class LogAnalyzer2Tests
{
[Test]
 public void Analyze_WebServiceThrows_SendsEmail()
 {
   StubService stubService = new StubService();
   stubService.ToThrow= new Exception("fake exception");
   MockEmailService mockEmail = new MockEmailService();

   LogAnalyzer2 log = new LogAnalyzer2();
   log.Service = stubService
   log.Email=mockEmail;
   string tooShortFileName="abc.ext";
   log.Analyze(tooShortFileName);

   Assert.AreEqual("a",mockEmail.To); //MOCKING USED
   Assert.AreEqual("fake exception",mockEmail.Body); //MOCKING USED
   Assert.AreEqual("subject",mockEmail.Subject);

 }
}

Я знаком с Arrange-Act-Assert, тогда один из способов объяснить разницу между заглушкой и макетом, которые могут быть полезны для вас, заключается в том, что заглушки относятся к сектору аранжировки, поскольку они предназначены для организации входного состояния и mocks относятся к секции assert, поскольку они предназначены для утверждения результатов против.

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

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