it-roy-ru.com

В чем разница между макетом и заглушкой?

Я читал различные статьи о насмешках против окурков в тестировании, в том числе Моты Мартина Фаулера не заглушки , но все еще не понимаю разницу.

749
never_had_a_name

Заглушка

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

Макет

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

Разница

Тесты, написанные с помощью макетов, обычно следуют шаблону initialize -> set expectations -> exercise -> verify для тестирования. В то время как предварительно написанная заглушка будет следовать initialize -> exercise -> verify

Сходство

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

604
Sean Copenhaver

Предисловие

Есть несколько определений объектов, которые не являются реальными. Общий термин test double. Этот термин включает в себя: dummy, fake, stub, mock.

Ссылка

Согласно статье Мартина Фаулера :

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

Стиль

Mocks vs Stubs = Поведенческое тестирование против государственного тестирования

Принцип

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

Жизненный цикл

Тест жизненного цикла с заглушками:

  1. Настройка - Подготовьте объект, который тестируется, и его заглушки.
  2. Упражнение - Проверьте функциональность.
  3. Проверить состояние - используйте подтверждения для проверки состояния объекта.
  4. Разрушение - Очистить ресурсы.

Тест жизненного цикла с макетами:

  1. Данные настройки - подготовьте объект, который тестируется.
  2. Настройка ожиданий - Подготовьте ожидания в макете, который используется основным объектом.
  3. Упражнение - Проверьте функциональность.
  4. Проверка ожиданий - Убедитесь, что в макете были вызваны правильные методы.
  5. Проверить состояние - используйте подтверждения для проверки состояния объекта.
  6. Разрушение - Очистить ресурсы.

Резюме

И тесты на макеты и заглушки дают ответ на вопрос: Каков результат?

Тестирование с макетами также интересует: Как был достигнут результат?

710
Ryszard Dżegan

Заглушка простой поддельный объект. Это просто гарантирует, что тест проходит гладко.
Макет умнее заглушки. Вы подтверждаете, что ваш тест проходит через него.

261
Arnis Lapsa

Вот описание каждого, за которым следует пример из реального мира.

  • Пустышка - просто фиктивные значения для удовлетворения API

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

  • Подделка - создать тестовую реализацию класса, которая может зависеть от некоторой внешней инфраструктуры. (Хорошей практикой является то, что ваш юнит-тестНЕфактически взаимодействует с внешней инфраструктурой.)

    Example: Создать фальшивую реализацию для доступа к базе данных, заменить ее на коллекцию in-memory.

  • Stub - переопределить методы для возврата жестко закодированных значений, также называемых state-based.

    Example: Ваш тестовый класс зависит от метода Calculate(), который занимает 5 минут. Вместо того, чтобы ждать 5 минут, вы можете заменить его реальную реализацию заглушкой, которая возвращает жестко закодированные значения; занимая лишь небольшую долю времени.

  • Макет - очень похож на Stub, но interaction-based, а не на основе состояния. Это означает, что вы не ожидаете от Mock возврата некоторого значения, а предполагаете, что выполняется определенный порядок вызовов методов.

    Пример: вы тестируете класс регистрации пользователя. После вызова Save он должен вызвать SendConfirmationEmail.

Stubs и Mocks на самом деле являются подтипами Mock, оба заменяют реальную реализацию тестовой реализацией, но по разным, конкретным причинам.

189
Lev

В codeschool.com course, Rails Testing for Zombies , они дают следующее определение терминов:

Огрызок

Для замены метода кодом, который возвращает указанный результат.

Издеваться

Заглушка с утверждением, что метод вызывается.

Так, как Шон Копенхейвер описал в своем ответе, разница в том, что издевательства устанавливают ожидания (то есть делают утверждения, о том, как их называют или как их называют).

160
Dillon Kearns

Заглушки не проваливаются, тестировать можно.

116
mk_

Я думаю, что самый простой и ясный ответ на этот вопрос дан из Роя Ошерова в его книге Искусство модульного тестирования (стр. 85)

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

С другой стороны, тест будет использовать фиктивный объект, чтобы проверить, является ли тест не пройден или нет. [...]

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

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

27
Ghini Antonio

Прочитав все объяснения, приведенные выше, я попытаюсь сжать:

  • Stub : фиктивный кусок кода, который позволяет запустить тест, но вам все равно, что с ним происходит.
  • Макет : фиктивный кусок кода, который вы ПРОВЕРЯЕТЕ, правильно вызывается как часть теста.
  • Spy : фиктивный фрагмент кода, который перехватывает некоторые вызовы реального фрагмента кода, позволяя вам проверять вызовы без замены всего исходного объекта.
19
O'Rooney

Mock - это просто тестирование поведения, обеспечивающее вызов определенных методов . Stub - это тестируемая версия (как таковая) конкретного объекта.

Что вы имеете в виду путь Apple?

18
NebulaFox

Я думаю, что самое важное различие между ними - это их намерения.

Позвольте мне попытаться объяснить это в ПОЧЕМУ заглушка против ПОЧЕМУ макет

Предположим, я пишу тестовый код для общедоступного контроллера временной шкалы моего Mac-клиента

Вот тестовый образец кода

Twitter_api.stub(:public_timeline).and_return(public_timeline_array)
client_ui.should_receive(:insert_timeline_above).with(public_timeline_array)
controller.refresh_public_timeline
  • STUB: Сетевое подключение к Twitter API очень медленное, что делает мой тест медленным. Я знаю, что он вернет временные шкалы, поэтому я сделал заглушку, имитирующую HTTP Twitter API, чтобы мой тест выполнялся очень быстро, и я могу запустить тест даже в автономном режиме. 
  • MOCK: Я еще не написал ни один из моих методов пользовательского интерфейса, и я не уверен, какие методы мне нужно написать для моего объекта пользовательского интерфейса. Я надеюсь узнать, как мой контроллер будет взаимодействовать с моим объектом пользовательского интерфейса, написав тестовый код.

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

Я предлагаю прочитать эту статью, если вы пытаетесь узнать больше о макетах: http://jmock.org/oopsla2004.pdf

17
Joe Yang

Если вы сравните это с отладкой:

Stub это как проверка того, что метод возвращает правильное значение

Mock это то же самое, что на самом деле войти в метод и убедиться, что все внутри правильно, прежде чем возвращать правильное значение.

14
happygilmore

Быть очень понятным и практичным:

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

Пример в JavaScript:

var Stub = {
   method_a: function(param_a, param_b){
      return 'This is an static result';
   }
}

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

Как говорит @mLevan, представьте в качестве примера, что вы тестируете класс регистрации пользователей. После вызова Save, он должен вызвать SendConfirmationEmail.

Очень глупый код Пример:

var Mock = {
   calls: {
      method_a: 0
   }

   method_a: function(param_a, param_b){
     this.method_a++; 
     console.log('Mock.method_a its been called!');
   }
}
13
R01010010

Этот слайд объясняет основные отличия очень хорошо.

 enter image description here

* Из лекции 16 CSE 403, Университет Вашингтона (слайд, созданный Марти Степпом)

11
Aviram Fireberger

Использование ментальной модели действительно помогло мне понять это, а не все объяснения и статьи, которые не совсем "утонули".

Представьте, что у вашего ребенка на столе стеклянная тарелка, и он начинает с ней играть. Теперь вы боитесь, что оно сломается. Итак, вместо этого вы даете ему пластиковую тарелку. Это было бы Mock (такое же поведение, тот же интерфейс, "более мягкая" реализация). 

Теперь, скажем, у вас нет замены пластика, поэтому вы объясняете: «Если вы продолжите играть с ним, он сломается!». Это заглушка , вы заранее указали заранее заданное состояние.

A Dummy будет вилкой, которую он даже не использовал ... и Spy может быть что-то вроде предоставления того же объяснения, которое вы уже использовали, которое сработало. A Фальшивка будет похоже на ложь, что полицейский придет, если он продолжит (не уверен насчет последней части :).

10
Moshisho

Мне нравится объяснение Роя Ошерова [ссылка на видео] .

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

10
nitishagar

A fake - это общий термин, который можно использовать для описания заглушки .__ или фиктивного объекта (рукописного или иного), потому что они оба похожи на Реальный объект.

Является ли подделка заглушкой или макетом, зависит от того, как она используется в текущем тесте. Если он используется для проверки взаимодействия (утверждается против), это объект Mock. В противном случае, это заглушка.

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

Что означает плавный тест?
Пример нижеприведенного кода:

 public void Analyze(string filename)
        {
            if(filename.Length<8)
            {
                try
                {
                    errorService.LogError("long file entered named:" + filename);
                }
                catch (Exception e)
                {
                    mailService.SendEMail("[email protected]", "ErrorOnWebService", "someerror");
                }
            }
        }

Вы хотите протестировать метод mailService.SendEMail (), для этого вам нужно смоделировать исключение в вашем тестовом методе, поэтому вам просто нужно создать класс Fake Stub errorService для имитации этого результата, тогда ваш тестовый код будет быть в состоянии проверить метод mailService.SendEMail (). Как вы видите, вам нужно смоделировать результат из другого класса External Dependency ErrorService. 

8
Mustafa Ekici
  • Стабс против Мокса
    • Заглушки
      1. дать конкретные ответы на вызовы методов
        • ex: myStubbedService.getValues ​​() просто возвращает строку, необходимую для тестируемого кода
      2. используется тестируемым кодом для его изоляции
      3. не может пройти тест
        • ex: myStubbedService.getValues ​​() просто возвращает значение заглушки
      4. часто реализуют абстрактные методы
    • Mocks
      1. «суперсет» пней; Можно утверждать, что определенные методы вызываются
        • ex: убедитесь, что myMockedService.getValues ​​() вызывается только один раз
      2. используется для проверки поведения тестируемого кода
      3. может не пройти тест
        • пример: убедитесь, что myMockedService.getValues ​​() был вызван один раз; проверка не пройдена, потому что myMockedService.getValues ​​() не был вызван моим протестированным кодом
      4. часто издевается над интерфейсами
7
Relu Mesaros

давайте посмотрим тест двойников:

  • Fake: Подделки - это объекты, которые имеют рабочие реализации, но не совпадают с производственными. Например,: реализация объекта доступа к данным или репозитория в памяти. 
  • Stub: Stub - это объект, который содержит предопределенные данные и использует их для ответа на вызовы во время тестов. Например,: объект, который должен получить некоторые данные из базы данных, чтобы ответить на вызов метода. 

  • Mocks: Mocks - это объекты, которые регистрируют вызовы, которые они получают . В тестовом утверждении мы можем проверить по Mocks, что все ожидаемые действия были выполнены. Например,: функциональность, которая вызывает службу отправки электронной почты ... для получения дополнительной информации просто проверьте это .

7
Alireza Rahmani Khalili

Прямо из статьи Роли, а не объекты , разработчики jMock:

Заглушки - это фиктивные реализации производственного кода, которые возвращают canned Результаты. Ложные объекты действуют как заглушки, но также включают в себя утверждения в инструмент взаимодействия целевого объекта с его соседями.

Итак, основные отличия:

  • ожидания, заданные для заглушек, обычно являются общими, в то время как ожидания, заданные для заглушек, могут быть более «умными» (например, вернуть это при первом вызове, это при втором и т. д.).
  • stubs в основном используются для настройки косвенных входов SUT, а mocks может использоваться для проверки как косвенных входов, так и косвенных выходов SUT.

Подводя итог, мы также пытаемся рассеять путаницу из статьи Фаулера title: mocks - это заглушки, но они не только заглушки.

6
Dimos

Я наткнулся на эту интересную статью UncleBob Маленький пересмешник . Это объясняет всю терминологию в очень простой для понимания форме, поэтому она полезна для начинающих. Статья Мартина Фаулерса очень читаема, особенно для начинающих, как я.

3
A.I

Ниже приведен пример использования mocks против заглушек с использованием C # и инфраструктуры Moq. В Moq нет специального ключевого слова для Stub, но вы можете использовать объект Mock для создания заглушек. 

namespace UnitTestProject2
{
    using Microsoft.VisualStudio.TestTools.UnitTesting;
    using Moq;
    [TestClass]
    public class UnitTest1
    {
        /// <summary>
        /// Test using Mock to Verify that GetNameWithPrefix method calls Repository GetName method "once" when Id is greater than Zero
        /// </summary>
        [TestMethod]
        public void GetNameWithPrefix_IdIsTwelve_GetNameCalledOnce()
        {
            // Arrange 
            var mockEntityRepository = new Mock<IEntityRepository>();
            mockEntityRepository.Setup(m => m.GetName(It.IsAny<int>()));

            var entity = new EntityClass(mockEntityRepository.Object);
            // Act 
            var name = entity.GetNameWithPrefix(12);
            // Assert
            mockEntityRepository.Verify(m => m.GetName(It.IsAny<int>()), Times.Once);
        }
        /// <summary>
        /// Test using Mock to Verify that GetNameWithPrefix method doesn't call Repository GetName method when Id is Zero
        /// </summary>
        [TestMethod]
        public void GetNameWithPrefix_IdIsZero_GetNameNeverCalled()
        {
            // Arrange 
            var mockEntityRepository = new Mock<IEntityRepository>();
            mockEntityRepository.Setup(m => m.GetName(It.IsAny<int>()));
            var entity = new EntityClass(mockEntityRepository.Object);
            // Act 
            var name = entity.GetNameWithPrefix(0);
            // Assert
            mockEntityRepository.Verify(m => m.GetName(It.IsAny<int>()), Times.Never);
        }
        /// <summary>
        /// Test using Stub to Verify that GetNameWithPrefix method returns Name with a Prefix
        /// </summary>
        [TestMethod]
        public void GetNameWithPrefix_IdIsTwelve_ReturnsNameWithPrefix()
        {
            // Arrange 
            var stubEntityRepository = new Mock<IEntityRepository>();
            stubEntityRepository.Setup(m => m.GetName(It.IsAny<int>()))
                .Returns("Stub");
            const string EXPECTED_NAME_WITH_PREFIX = "Mr. Stub";
            var entity = new EntityClass(stubEntityRepository.Object);
            // Act 
            var name = entity.GetNameWithPrefix(12);
            // Assert
            Assert.AreEqual(EXPECTED_NAME_WITH_PREFIX, name);
        }
    }
    public class EntityClass
    {
        private IEntityRepository _entityRepository;
        public EntityClass(IEntityRepository entityRepository)
        {
            this._entityRepository = entityRepository;
        }
        public string Name { get; set; }
        public string GetNameWithPrefix(int id)
        {
            string name = string.Empty;
            if (id > 0)
            {
                name = this._entityRepository.GetName(id);
            }
            return "Mr. " + name;
        }
    }
    public interface IEntityRepository
    {
        string GetName(int id);
    }
    public class EntityRepository:IEntityRepository
    {
        public string GetName(int id)
        {
            // Code to connect to DB and get name based on Id
            return "NameFromDb";
        }
    }
}
3
Adarsh Shah

Точка зрения заглушки и пробного теста:

  • Stub является фиктивной реализацией, выполненной пользователем в static way, т.е. в Stub при написании кода реализации. Таким образом, он не может обрабатывать определение сервиса и динамическое состояние. Обычно это делается в платформе JUnit без использования фреймворка. 

  • Mock также является фиктивной реализацией, но ее реализация завершена динамически путем использования сред Mocking, таких как Mockito. Таким образом, мы можем обрабатывать определение условий и сервисов как динамический способ, то есть макеты могут создаваться динамически из кода во время выполнения. Таким образом, используя mock, мы можем динамически реализовывать Stubs.

3
Premraj

Заглушка помогает нам запустить тест. Как? Это дает значения, которые помогают запустить тест. Эти значения сами по себе не являются реальными, и мы создали эти значения только для запуска теста. Например, мы создаем HashMap, чтобы дать нам значения, которые аналогичны значениям в таблице базы данных. Поэтому вместо непосредственного взаимодействия с базой данных мы взаимодействуем с Hashmap.

Mock это фальшивый объект, который запускает тест. где мы утверждаем.

2
user965884

Пример Мокито

 enter image description here

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

Mock object предоставляет способ проверить, вызывал ли тестируемый объект определенные методы.

И, как сказал Мартин Фаулер в своем эссе

Разница в том, что stub использует проверку состояния, а mock использует проверку поведения.

Читать дальше здесь и здесь

2
yoAlex5

Заглушка - это пустая функция, которая используется во избежание необработанных исключений во время тестов:

function foo(){}

Макет - это искусственная функция, которая используется во избежание зависимостей ОС, среды или оборудования во время тестов:

function foo(bar){ window = this; return window.toString(bar); }

С точки зрения утверждений и состояния:

  • Мокки утверждаются до изменения события или состояния
  • Заглушки не утверждаются, они обеспечивают состояние перед событием, чтобы избежать выполнения кода из несвязанных модулей
  • Шпионы настраиваются как заглушки, а затем утверждаются после изменения события или состояния
  • Подделки не утверждаются, они запускаются после события с жестко закодированными зависимостями, чтобы избежать состояния

Рекомендации

2
Paul Sweatte

там много правильных ответов, но я думаю, что стоит упомянуть эту форму, дядя Боб: https://8thlight.com/blog/uncle-bob/2014/05/14/TheLittleMocker.html

лучшее объяснение с примерами!

2
Kasper

Я использовал примеры Python в своем ответе, чтобы проиллюстрировать различия.

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

class Foo(object):
    def bar1(self):
        pass

    def bar2(self):
        #or ...
        raise NotImplementedError

    def bar3(self):
        #or return dummy data
        return "Dummy Data"

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

mymodule.py:

import os
import os.path

def rm(filename):
    if os.path.isfile(filename):
        os.remove(filename)

test.py:

from mymodule import rm
import mock
import unittest

class RmTestCase(unittest.TestCase):
    @mock.patch('mymodule.os')
    def test_rm(self, mock_os):
        rm("any path")
        # test that rm called os.remove with the right parameters
        mock_os.remove.assert_called_with("any path")

if __== '__main__':
    unittest.main()

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

Больше на unittest.mock , заметка в python 2.x mock не включена в unittest, но является загружаемым модулем, который можно скачать через pip (pip install mock).

Я также прочитал «Искусство модульного тестирования» Роя Ошерова, и я думаю, было бы здорово, если бы подобная книга была написана с использованием примеров Python и Python. Если кто-нибудь знает о такой книге, пожалуйста, поделитесь. Ура :)

2
radtek

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

2
simon.denel

Испытуемый выполняет действия в ответ на определенные подсказки (вызовы функций) или другие стимулы. Вот конкретные примеры тестовых ситуаций.

Сценарий - EMT студенческий экзамен

Студент учился на врача скорой медицинской помощи. Если вы не знакомы с этой тестовой ситуацией, посмотрите на Яна Галлахера в Shameless 6 сезон, эпизод 10.

Слишком дорого находить пациентов с различными заболеваниями для целей тестирования. Вместо этого мы используем актеров. Мы спрашиваем испытуемого (Ян): «Вы прибыли на место происшествия, а пациент обездвижен и потерял сознание, что вы делаете в первую очередь?» Ян отвечает: «Я проверяю, безопасна ли сцена». И инструктор по испытанию говорит, что «сцена безопасна».

Инструктор (и актер) могут вводить произвольные ответы на запросы испытуемого.

Здесь инструктор (и актер) являются издевательством. Медицинская подготовка использует эту терминологию (например, симуляцию имитационного кода) так же, как и компьютерные ученые.

Сценарий - зарегистрироваться на сайте

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

Веб-сайт требует, чтобы вам исполнилось 21 год. Таким образом, вы вводите значение 1 января 1970 года. Оно соответствует требованиям и избавляет вас от трудоемкого процесса внедрения процесса «запомни мой день рождения и набери его».

Эта дата заглушка. Использование этого слова специфично для информатики.

1
William Entriken

Заглушка - это объект, который реализует интерфейс компонента, но вместо того, чтобы возвращать то, что компонент будет возвращать при вызове, заглушка может быть настроена на возвращение значения, подходящего для теста. Используя заглушки, модульный тест может проверить, может ли модуль обрабатывать различные возвращаемые значения от своего соавтора. Использование заглушки вместо реального сотрудника в модульном тесте можно выразить так:

модульный тест -> заглушка

юнит тест -> юнит -> заглушка

модульный тест утверждает результаты и состояние объекта

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

A Mockпохож на заглушку, только у него есть методы, позволяющие определить, какие методы были вызваны для Mock. Таким образом, используя макет, можно проверить, может ли устройство правильно обрабатывать различные возвращаемые значения, а также правильно ли оно использует коллаборатор. Например, по значению, возвращенному из объекта dao, вы не можете увидеть, были ли данные прочитаны из базы данных с помощью Statement или PreparedStatement. Также вы не можете увидеть, был ли вызван метод connection.close () перед возвратом значения. Это возможно с насмешками. Другими словами, имитация позволяет проверить целостность взаимодействия юнитов с коллаборатором. Не только методы коллаборатора, которые возвращают значения, используемые модулем. Использование макета в модульном тесте можно выразить так:

модульный тест -> макет

юнит тест -> юнит -> макет

модульный тест утверждает результат и состояние модуля

модульный тест утверждает на методы, вызываемые на макете

Подробнее >> Здесь

1
M_ Fa

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

0
Elisabeth

Mock - Mock перехватывает вызов метода или функции (или группы методов и функций, как в случае смоделированного класса). Это не альтернатива этому методу или функции. При таком перехвате макет может делать все, что захочет, например записывать ввод и вывод, принимать решение замкнуть вызов, изменить возвращаемое значение и т.д.

Заглушка - Заглушка - это действительная полная рабочая реализация метода или функции (или группы методов и функций, как в случае с классом-заглушкой), которая имеет идентичный интерфейс/сигнатуру для метода, функции или группы методы и функции, для которых это заглушка. Реализация с заглушками, как правило, будет делать только то, что приемлемо в контексте модульного теста, то есть, например, она не будет выполнять IO, имитируя поведение вещи, которую она заглушает.

0
Didier A.

Скажем, у вас есть класс EmployeeService, который вы хотите протестировать и который имеет одну зависимость от интерфейса EmployeeDao:

public class EmployeeService{
   private EmployeeDao dao;
   public EmployeeService(Dao dao){this.dao = dao;}

   public String getEmployeeName(int id){
     Employee emp = bar.goToDatabaseAndBringTheEmployeeWithId(id);
     return emp != null?emp.getFullName:null;
   }
   //Further state and behavior
}

public interface EmployeeDao{
  Employee goToDatabaseAndBringTheEmployeeWithId(int id);
}

Внутри вашего тестового класса:

public class EmployeeServiceTest{
   EmployeeService service;
   EmployeeDao mockDao = Mockito.mock(EmployeeDao.class);//Line 3

   @Before
   public void setUp(){
     service = new EmployeeService(mockDao);
   }
   //Tests
   //....
}

В приведенном выше тестовом классе в строке 3 мы говорим фальшивой структуре (в данном случае Mockito): «Привет, Mockito, создай мне объект, который имеет функциональность EmployeeDao». Фреймворк собирается создать объект, имеющий метод goToDatabaseAndBringTheEmployeeWithId, но на самом деле без тела. Твоя работа - инструктировать эту шутку, что делать. Это издевательство.

Но вы также можете создать класс, который реализует интерфейс EmployeeDao, и использовать его вместо этого в тестовом классе:

public EmployeeDaoStub implements EmployeeDao{
   public Employee goToDatabaseAndBringTheEmployeeWithId(int id){
      //No trip to DB, just returning a dummy Employee object
      return new Employee("John","Woo","123 Lincoln str");
   }
}

На этот раз в вашем тестовом классе вместо заглушки используется заглушка:

public class EmployeeServiceTest{
   EmployeeService service;
   EmployeeDao daoStub = new EmployeeDaoStub();//Line 3

   @Before
   public void setUp(){
     service = new EmployeeService(daoStub);
   }
   //Tests
   //....
}

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

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

0
Mikayil Abdullayev

И заглушки, и Mocks перекрывают внешние зависимости, но разница в том,

Заглушки -> Для проверки данных

издевается -> для проверки поведения


Fake/Dummy -> Ничего не тестировать (просто переопределите функциональность пустыми методами, например, замените Logger, чтобы избежать каких-либо шумов во время тестирования)

0
Developer

следующее мое понимание ...

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

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

0
Andy Lin