Важна ли разница между разными тестами?

Question

Я только что прочитал пост Мартина Фаулера Насмешки - это не заглушки .Он определяет разные тестовые двойники (или, скорее, ссылается на книгу шаблонов Джерарда Месароса ):

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

Первая часть моего вопроса будет такой:это даже авторитетно?Широко ли используется и понимается этот язык?

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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