Понимание заглушек, фейков и моков.

Я только что начал читать Профессиональная разработка через тестирование с помощью C #: разработка реальных Мировые приложения с TDD

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

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

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

Может ли кто-нибудь объяснить мне эту концепцию?


person aleczandru    schedule 15.02.2013    source источник
comment
Прочтите этот xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and% 20Dummies.html и этот martinfowler.com/articles/mocksArentStubs.html   -  person blank    schedule 15.02.2013
comment
И пока вы это делаете, вы можете также прочитать этот mockobjects.com/files/mockrolesnotobjects.pdf   -  person blank    schedule 15.02.2013
comment
Я надеюсь, вы простите рекламу, но мы написали целую книгу Growing Object Oriented Software, в которой рассказывается о мотивации использования моков.   -  person Steve Freeman    schedule 27.04.2013


Ответы (3)


Как я читал в прошлом, вот что, как мне кажется, означает каждый термин

Заглушка

Здесь вы заменяете результат метода на известное значение, чтобы код работал без проблем. Например, допустим, у вас было следующее:

public int CalculateDiskSize(string networkShareName)
{
    // This method does things on a network drive.
}

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

В итоге вы делаете что-то вроде:

sut.WhenCalled(() => sut.CalculateDiskSize()).Returns(10);

Подделка

С помощью подделки вы возвращаете поддельные данные или создаете поддельный экземпляр объекта. Классическим примером являются классы репозитория. Возьмите этот метод:

public int CalculateTotalSalary(IList<Employee> employees) { }

Обычно вышеуказанный метод передается коллекции сотрудников, считанных из базы данных. Однако в ваших модульных тестах вы не хотите получать доступ к базе данных. Итак, вы создаете поддельный список сотрудников:

IList<Employee> fakeEmployees = new List<Employee>();

Затем вы можете добавить элементы в fakeEmployees и подтвердить ожидаемые результаты, в данном случае общую зарплату.

Моки

При использовании фиктивных объектов вы намереваетесь проверить какое-то поведение или данные на этих фиктивных объектах. Пример:

Вы хотите убедиться, что определенный метод был выполнен во время тестового запуска, вот общий пример с использованием фреймворка Moq mocking:

public void Test()
{
    // Arrange.
    var mock = new Mock<ISomething>();

    mock.Expect(m => m.MethodToCheckIfCalled()).Verifiable();

    var sut = new ThingToTest();

    // Act.
    sut.DoSomething(mock.Object);

    // Assert
    mock.Verify(m => m.MethodToCheckIfCalled());
}

Надеюсь, это поможет немного прояснить ситуацию.

РЕДАКТИРОВАТЬ: Рой Ошеров - хорошо известный сторонник разработки через тестирование, и у него есть очень хорошая информация по этой теме. Вы можете найти это очень полезным:

http://artofunittesting.com/

person Jason Evans    schedule 15.02.2013
comment
очень информативно. Я всегда думал, что подделки и имитация взаимозаменяемы. Здесь я каждый день узнаю что-то новое :) +1 - person bas; 15.02.2013
comment
что такое в Mocks? и является ли ISomething тем классом, который мы тестируем? - person fersarr; 19.08.2015
comment
m - это параметр, который передается в функцию Expect(). Это лямбда-выражение. Он нигде не объявлен, он просто существует внутри лямбда Expect(). var mock = new Mock<ISomething>(); означает, что вы создаете объект, реализующий ISomething, поэтому ISomething - это интерфейс, а не объект. Затем вы можете использовать mock для управления реакцией методов при их вызове, например, с помощью функции Expect(). - person Jason Evans; 19.08.2015

Все они являются вариациями Test Double. Вот очень хорошая ссылка, объясняющая различия между ними: http://xunitpatterns.com/Test%20Double.html

Также из сообщения Мартина Фаулера: http://martinfowler.com/articles/mocksArentStubs.html

Месарос использует термин Test Double как общий термин для любого типа воображаемого объекта, используемого вместо реального объекта в целях тестирования. Название происходит от понятия «дублер-каскадер» в кино. (Одна из его целей состояла в том, чтобы избежать использования какого-либо имени, которое уже широко использовалось.) Затем Месарос определил четыре конкретных вида двойника:

  1. Фиктивные объекты: передаются, но на самом деле никогда не используются. Обычно они используются просто для заполнения списков параметров.
  2. Поддельные объекты на самом деле имеют работающие реализации, но обычно требуют некоторого сокращения, что делает их непригодными для производства (хорошим примером является база данных в памяти).
  3. Заглушки предоставляют стандартные ответы на звонки, сделанные во время теста, обычно не отвечая ни на что, кроме того, что запрограммировано для теста. Заготовки также могут записывать информацию о вызовах, например, заглушку шлюза электронной почты, которая запоминает «отправленные» сообщения или, возможно, только то, сколько сообщений «отправлено».
  4. Мы говорим здесь о макетах: объекты, заранее запрограммированные с ожиданиями, которые формируют спецификацию вызовов, которые они, как ожидается, получат.

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

person Raj Rao    schedule 25.11.2014

Это руководство по PHP-модулю очень помогло мне в качестве введения:

«Иногда просто протестировать тестируемую систему (SUT) просто сложно, потому что это зависит от других компонентов, которые нельзя использовать в тестовой среде. Это может быть потому, что они недоступны, они не будут возвращать результаты, необходимые для test или потому, что их выполнение будет иметь нежелательные побочные эффекты. В других случаях наша стратегия тестирования требует от нас большего контроля или видимости внутреннего поведения SUT ». Подробнее: https://phpunit.de/manual/current/en/test-doubles.html

И я нахожу лучшие "вводные" при поиске "тестовых двойников", поскольку известны подделки, подделки, заглушки и т. Д.

person R01010010    schedule 16.11.2014