Я знаю, что это старый вопрос, но ни одно из этих решений не разработано для меня. Я закончил использовать offset (). Top, чтобы получить желаемые результаты. Вот что я использовал для мягкой прокрутки экрана до последнего сообщения в приложении для чата:
$("#html, body").stop().animate({
scrollTop: $("#last-message").offset().top
}, 2000);
Надеюсь, это поможет кому-то другому.
Stub
Я считаю, что самое большое различие заключается в том, что заглушка, которую вы уже написали с предопределенным поведением. Таким образом, у вас будет класс, который реализует зависимость (абстрактный класс или интерфейс, скорее всего), которые вы притворяетесь для целей тестирования, и методы будут просто пропущены с заданными ответами. Они не сделали бы ничего необычного, и вы бы уже написали закодированный код для него вне вашего теста.
Mock
Макет - это то, что в рамках вашего теста вы должны с вашими ожиданиями. Макет не настроен заранее, так что у вас есть код, который делает это в вашем тесте. Mocks в пути определяется во время выполнения, так как код, который устанавливает ожидания, должен выполняться до того, как они что-либо сделают.
Разница
Тесты, написанные с помощью mocks, обычно следуют шаблону initialize -> set expectations -> exercise -> verify
тестирование. Хотя предварительно написанная заглушка будет следовать за initialize -> exercise -> verify
.
Сходство
Цель состоит в том, чтобы исключить тестирование всех зависимостей класса или функции, чтобы ваши тесты были более целенаправленными и более простыми в том, что они пытаются доказать.
Я наткнулся на эту интересную статью от UncleBob The Little Mocker . Это объясняет всю терминологию очень легко понять, поэтому она полезна для новичков. Статья Мартина Фаулерса читается специально для начинающих, таких как я.
Я думаю, что самое важное различие между ними - их намерения.
Позвольте мне объяснить это в WHY stub vs. WHY mock
Предположим, что я пишу тестовый код для
[x6]
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
Написав mock, вы обнаружите, что отношения сотрудничества с объектами проверяются, когда ожидание выполняется, тогда как только stub имитирует поведение объекта.
Предлагаю прочитать эту статью, если вы хотите узнать больше о mocks: http://jmock.org/oopsla2004.pdf
См. ниже пример mocks vs stub с использованием 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";
}
}
}
следующее - мое понимание ...
Этот слайд объясняет основные различия очень хорошо.
* Из CSE 403 Лекция 16, Вашингтонский университет (слайд, созданный «Marty Stepp «)
Mock - макет перехватывает вызов метода или функции (или группы методов и функций, например, в случае классного класса). Это не альтернатива этому методу или функции. В этом перехвате макет может делать все, что захочет, например записывать вход и выход, принимать решение об коротком замыкании вызова, изменять возвращаемое значение и т. Д.
Stub - заглушка является действительной полной работой реализация метода или функции (или группы методов и функций, например, в случае закодированного класса), который имеет идентичный интерфейс / подпись для метода, функции или группы методов и функций, для которых он выполняется. Зарезервированная реализация, как правило, будет делать только то, что приемлемо в контексте единичного теста, а это значит, что он не будет выполнять IO, например, при одновременном подражании поведению вещи, которую он забивает.
В курсе codeschool.com , Rails Testing для Zombies , они дают это определение терминов:
Stub
< blockquote>Для замены метода кодом, возвращающим заданный результат.
Mock
Заглушка с утверждением о вызове метода.
Итак, как сказал Шон Копенгавер в своем ответе, разница в том, что издеваются над ожиданиями (т. е. делают утверждения, о том, вызваны ли они или как они вызваны).
Справа от статьи Mock Roles, а не Objects , разработчиками jMock:
Stub - это фиктивные реализации производственного кода, которые возвращают законченные результаты. Mock Objects действуют как заглушки, но также включают в себя утверждения для взаимодействия взаимодействий целевого объекта со своими соседями.
Итак, основными отличиями являются:
- ожидания, установленные на заглушках, обычно являются общими, в то время как ожидания, установленные на mocks, могут быть более «умными» (например, вернуть это при первом вызове, это на втором и т. д.).
- заглушки в основном используются для настройки косвенных входы SUT, в то время как макеты могут использоваться для тестирования как косвенных входов, так и косвенных выходов SUT.
Подводя итог, также пытаясь разогнать путаницу из статьи Фаулера title: mocks - это заглушки, но они не только заглушки.
Штыри используются для методов с ожидаемым возвращаемым значением, которое вы настраиваете в своем тесте. Mocks используются для методов void, которые проверяются в Assert, которые они вызывают.
Если вы сравниваете его с отладкой:
Stub похож на то, чтобы убедиться, что метод возвращает правильное значение
. Mock похож на фактически вступающий в метод и убедившись, что все внутри правильное значение перед возвратом правильного значения.
blockquote>
Штук - простой поддельный объект. Это просто гарантирует, что тест проходит гладко. Макет более умный. Вы подтверждаете, что ваш тест проходит через него.
много действительных ответов там, но я думаю, стоит упомянуть эту форму дядя боб: https://8thlight.com/blog/uncle-bob/2014/05/14/TheLittleMocker.html
лучшее объяснение с примерами!
Штыри не терпят неудачу в ваших тестах, макет может.
Подделка fake - это общий термин, который может использоваться для описания либо заглушки, либо макетного объекта (рукописного или иного), потому что оба они выглядят как реальный объект.
]
Является ли подделка заглушкой или макетом, зависит от того, как она используется в текущем тесте. Если он используется для проверки взаимодействия (утверждается против), это макет объекта. В противном случае это заглушка.Fakes гарантирует, что тест будет выполняться плавно. Это означает, что читатель вашего будущего теста поймет, каким будет поведение поддельного объекта, без необходимости читать его исходный код (без необходимости зависеть от внешнего ресурса).
Что означает тестовый запуск? Например, в нижеприведенном коде:
public void Analyze(string filename)
{
if(filename.Length<8)
{
try
{
errorService.LogError("long file entered named:" + filename);
}
catch (Exception e)
{
mailService.SendEMail("admin@hotmail.com", "ErrorOnWebService", "someerror");
}
}
}
Вы хотите протестировать метод mailService.SendEMail () , чтобы сделать это, чтобы вы могли имитировать исключение в вашем тестовом методе, так что вы просто необходимо создать класс Fake Stub errorService для имитации этого результата, тогда ваш тестовый код сможет протестировать метод mailService.SendEMail (). Как вы видите, вам нужно смоделировать результат, который является результатом другого класса External Dependency ErrorService.
A Stub - это объект, который реализует интерфейс компонента, но вместо того, чтобы возвращать то, что компонент будет возвращать при вызове, заглушку можно настроить для возврата значения, которое соответствует тесту. Используя заглушки, единичный тест может проверить, может ли блок обрабатывать различные возвращаемые значения от своего соавтора. Использование заглушки вместо реального соавтора в единичном тесте может быть выражено следующим образом:
unit test -> stub
unit test -> unit -> stub
unit test утверждает результаты и состояние устройства
. Сначала тестовый модуль создает заглушку и настраивает возвращаемые значения. Затем модульный тест создает блок и устанавливает на него заглушку. Теперь модульный тест вызывает устройство, которое, в свою очередь, вызывает заглушку. Наконец, модульный тест делает утверждения о результатах вызова метода на единицу.
Mock похож на заглушку, только он также имеет методы, позволяющие определить, какие методы вызывают в Mock. Используя макет, можно, таким образом, проверить, правильно ли устройство может обрабатывать различные возвращаемые значения, а также если устройство правильно использует соавтор. Например, вы не можете увидеть значение, возвращаемое с объекта dao, если данные были прочитаны из базы данных с помощью Statement или PreparedStatement. Также вы не видите, был ли вызван метод connection.close () перед возвратом значения. Это возможно с издевательствами. Другими словами, mocks позволяет тестировать полное взаимодействие блоков с сотрудником. Не только методы соавтора, возвращающие значения, используемые устройством. Использование макета в единичном тесте может быть выражено следующим образом:
unit test -> mock
unit test -> unit -> mock
unit test утверждает, что результат и состояние единицы
unit test подтверждают методы, называемые mock
Подробнее >> Здесь
Мне нравится объяснение, высказанное Роем Ошеровым [видео ссылка] .
Каждый созданный класс или объект является Fake. Это макет, если вы проверяете на него вызовы. В противном случае это заглушка.
Прочитав все объяснения выше, позвольте мне попытаться сконденсироваться:
Я думаю, что самый простой и ясный ответ на этот вопрос дан Роем Ошеровым в его книге Искусство модульного тестирования (стр. 85)
Самый простой способ сказать, что мы имеем дело с заглушкой, - это заметить, что заглушка никогда не сможет пропустить тест. Утверждения, что использование тестов всегда противоречит тестируемому классу.
С другой стороны, тест будет использовать макетный объект, чтобы проверить, не прошел тест или нет. [...]
Опять же, макет-объект - это объект, который мы используем, чтобы проверить, не прошел тест или нет.
Это означает, что если вы делаете утверждения против подделка означает, что вы используете фальшивку как макет, если вы используете фальшивку только для запуска теста без утверждения над ним, вы используете подделку как заглушку.
Штук - это пустая функция, которая используется во избежание необработанных исключений во время тестов:
function foo(){}
Макет - это искусственная функция, которая используется для предотвращения зависимостей ОС, окружения или оборудования во время тестов:
function foo(bar){ window = this; return window.toString(bar); }
В терминах утверждений и состояний:
Точка проверки на наличие заглушки и макета:
Быть предельно ясным и практичным:
Stub: класс или объект, который реализует методы класса / объекта, которые будут подделаны, и всегда возвращает то, что вы хотите.
Пример в JavaScript:
var Stub = {
method_a: function(param_a, param_b){
return 'This is an static result';
}
}
Mock: то же самое, что и заглушка, но добавляет некоторую логику, которая «проверяет» при вызове метода, поэтому вы можете быть уверены, что некоторая реализация вызывает этот метод.
Как говорит @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!');
}
}
Я использовал примеры 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"
Макетные объекты используются в ложных тестовых случаях, они проверяют, что определенные методы вызываются на этих объектах. Макетные объекты - это моделируемые объекты, которые управляют действиями реальных объектов. Обычно вы создаете макет объекта для проверки поведения какого-либо другого объекта. Mocks позволяет имитировать ресурсы, которые либо недоступны, либо слишком громоздки для модульного тестирования.
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 __name__ == '__main__':
unittest.main()
Это очень простой пример, который просто запускает rm и утверждает параметр, с которым он был вызван. Вы можете использовать mock с объектами, а не только функциями, как показано здесь, и вы также можете вернуть значение, чтобы макет мог использоваться для замены заглушки для тестирования.
Подробнее о unittest.mock , примечание в python 2.x mock не входит в unittest, но является загружаемым модулем, который можно загрузить через pip (pip install mock).
Я также прочитал «The Art of Unit Testing «Роем Ошеровым, и я думаю, было бы здорово, если бы подобная книга была написана с использованием примеров Python и Python. Если кто-нибудь знает такую книгу, пожалуйста, разделите. Приветствия:)
Вот описание каждого из них, за которым следует образец реального мира.
API
. Пример : Если вы тестируете метод класса, который требует много обязательных параметров в конструкторе, который не имеет эффекта в вашем тесте, тогда вы можете создать фиктивные объекты для цель создания новых экземпляров класса. in-memory
. state-based
. Пример : ваш тестовый класс зависит от метода Calculate()
, который занимает 5 минут. Вместо того, чтобы ждать 5 минут, вы можете заменить его реальную реализацию заглушкой, которая возвращает жестко заданные значения; занимая лишь небольшую часть времени. Stub
, но interaction-based
, а не на состояние. Это означает, что вы не ожидаете, что Mock
вернет некоторое значение, но предположим, что выполняется конкретный порядок вызовов методов. Пример. Вы тестируете класс регистрации пользователя. После вызова Save
он должен вызвать SendConfirmationEmail
. Stubs
и Mocks
на самом деле являются подтипами Mock
, и реальная реализация swap с тестовой реализацией, но по разным конкретным причинам.
Mock - это просто тестирование поведения, следя за тем, чтобы вызывались определенные методы.
Что вы подразумеваете под Apple?
Существует несколько определений объектов, которые не являются реальными. Общий термин - тест двойной. Ссылка Согласно
- Объекты Dummy передаются, но никогда не используются. Обычно они используются для заполнения списков параметров.
- Фальшивые объекты фактически имеют рабочие реализации, но обычно используют некоторый ярлык, который делает их непригодными для производства (в качестве примера используется база данных с памятью).
- Штукеры предоставляют консервированные ответы на вызовы, сделанные во время теста, обычно вообще не реагируют на что-либо вне того, что запрограммировано для теста. Stubs также может записывать информацию о вызовах, таких как заглушка шлюза электронной почты, которая запоминает отправленные сообщения, или, может быть, только то, сколько сообщений он отправил.
- Mocks - это то, о чем мы говорим здесь: объекты, запрограммированные ожиданиями, которые формируют спецификацию ожидаемых вызовов.
Стиль
Mocks vs Stubs = Поведенческое тестирование vs State тестирование
Принцип
Согласно принципу Проверяйте только одну вещь на тест , в одном тесте может быть несколько заглушек, но обычно есть только один mock
Жизненный цикл
Жизненный цикл тестирования с заглушками:
- Настройка - подготовить тестируемый объект и его коллабораторы.
- Упражнение - проверить функциональность.
- Проверить состояние - использовать утверждения для проверки состояния объекта.
- Teardown - очистка ресурсов.
Test жизненный цикл с mocks:
- Данные установки - Подготовьте объект, который bein g
- Ожидания настройки - Подготовьте ожидания в макете, который используется первичным объектом.
- Упражнение - проверьте функциональность.
- Проверьте ожидания - убедитесь, что правильные методы были вызваны в mock.
- Проверить состояние - использовать утверждения для проверки состояния объекта.
- Teardown - очистить ресурсы.
Резюме
Оба теста mocks и stubs дают ответ на вопрос: Каков результат?
Тестирование с помощью mocks также интересует: How результат был достигнут?
Штук - это поддельный объект, созданный для целей тестирования. Макет - это заглушка, которая регистрирует, действительно ли ожидались ожидаемые вызовы.
Stub помогает нам запустить тест. Как? Он дает значения, которые помогают запустить тест. Эти значения сами по себе не являются реальными, и мы создали эти значения только для запуска теста. Например, мы создаем HashMap, чтобы дать нам значения, похожие на значения в таблице базы данных. Поэтому вместо прямого взаимодействия с базой данных мы взаимодействуем с Hashmap.
Mock - это поддельный объект, который запускает тест. где мы положим assert.