Важна ли разница между различными двойными экзаменами?

Question

Я просто читал сообщение Мартина Фаулера Mocks Aren't Stubs. Он определяет различные тестовые двойников (или, вернее, ссылается Gerard Meszaros-х xUnit patterns book):

• Фиктивные объекты передаются вокруг, но никогда не использовал. Обычно они используются только для заполнения списков параметров.
• Поддельные объекты на самом деле имеют рабочих реализаций, но обычно принимают некоторые ярлыки, что делает их не подходящими для производства (в базе данных памяти есть пример ).
• Штыри предоставляют законченные ответы на звонки, сделанные во время теста, обычно не реагируют вообще на что-либо вне того, что запрограммировано в для теста. Stubs также может записывать информацию о вызовах, таких как шлюз шлюза электронной почты, который запоминает сообщения, которые он отправил, или, может быть, , сколько всего сообщений, которые он отправил.
• Mocks - это объекты, запрограммированные с ожиданием, которые формируют спецификацию вызовов, которые они должны получить, .

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

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

• Все называется «макет». Либо вызывая метод Mockito.mock(), либо аннотацию @Mock, вы используете слово «mock» для создания mocks, stubs и иногда манекенов (если простое «новое» не будет делать). Исключение - это «шпион», который может использоваться для создания чего-то вроде «поддельного», но также может использоваться для проверки вашей системы.
• Даже если вам не важно имя метода для создания тестового двойника, двойник может быть проверен (или нет), и вы можете включить захват на этапе проверки, который, как представляется, включает в себя некоторые вещи, которые (помнящие звонки, которые были сделаны) и издевается (проверяя, что были сделаны определенные ожидаемые вызовы).

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

Answer 1

Английское слово «макет» означает «имитация меньшего качества, чем оригинал». Вот почему даже ручные издевательства (написанные без помощи каркаса вроде Мокито) иногда называются насмешками.

Язык, который использовал Мартин, теперь немного устарел. Он написал это в контексте старых издевательских фреймворков, таких как JMock, до появления «хороших макетов». В ту эпоху издевательства были строгими; любые взаимодействия, которые не были установлены и не ожидались, потерпят неудачу.

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

Моты для этих коллаборационистов, и мы не склонны больше полагаться на ожидания на издевательствах. Вместо этого мы настроили mocks для предоставления информации, затем подтвердили, что их попросили выполнить любые задания, которые необходимо выполнить. Mockito была первой основой для работы таким образом, и поэтому различие размыто - потому что, что бы вы ни делали, вы издеваетесь над соавтором, и вам больше не нужно настраивать ожидания. Moq работает так же в .NET.

Отличительные черты Mockito по умолчанию даже не заботятся, если вы их используете и не проверяете (хотя вам нужно будет установить любую информацию, которую они должны предоставить перед собой - эквивалент «заглушки») ,

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

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

Ранние рамки не обеспечивали такую ​​гибкость, следовательно, дифференциацию Мартина, предназначенную для того, чтобы помочь вам правильно использовать макеты. Надеюсь, это поможет прояснить ситуацию и объяснить, почему гибкость Mockito не является недостатком, но, как указывал David Wallace, - сила.

Answer 2

Собственно, это сила Мокито. Mockito mock - это объект, на котором вы можете либо «заглушить» методы, либо «проверить» методы, либо и то, и другое. (Выполнение обоих для одного и того же метода - это запах кода, но это еще одна тема). Таким образом, Mockito mock является «заглушкой» (в смысле Мартина Фаулера) и «макетом» (в смысле Мартина Фаулера); но вы не должны использовать его как и то, и другое. Как правило, макет Mockito будет действовать как «заглушка», ИЛИ как «макет»; реже, чем и то, и другое.

В некоторых других насмешливых фреймах у вас нет такого уровня гибкости. Если вы хотите сделать «проверку» на макет, вам также придется делать «stubbing». В этих рамках, mocks ДОЛЖНЫ действовать как «заглушка» и как «макет».Насколько я понимаю, одним из факторов, побудивших Щепана Фабера создать Мокито, было желание уметь отделять поведение «заглушки» и «макет» поведения (в строгих чувствах Мартина Фаулера обоих слов).

Answer 3

В соответствии с тем, что я понимаю из тестовых образцов X-Unit от Джерарда Мезароса, макет - это двойной тест, который включает в себя функциональность манекена, заглушки и шпиона. Вы можете проверить фактическое сравнение, которое он рисует о них в pg.742 этой книги.

Также this article может пролить свет на ваш вопрос. В этой статье четко говорится, что

«Макет динамически созданный макет библиотеки (остальные обычно получают с помощью теста-разработчика с использованием коды). Тест разработчик никогда не видит фактический код, реализующий интерфейс или базу class, , но может настроить макет для предоставления возвращаемых значений, ожидать определенных членов для вызова и т. д. В зависимости от его конфигурации макет может вести себя как манекен, заглушка или шпион."

Обе цитаты и изображение были взяты из this article. ИМХО, макет предназначен для стирают грань между соской, заглушкой и разведчика.