Вопрос по – Цель издевательства

6

Какова цель издеваться?

Я следовал некоторым учебникам ASP.NET MVC, которые используют NUnit для тестирования и Moq для насмешек. Я немного неясен насчет насмешливой части этого.

Ваш Ответ

8   ответов
3

& Quot; Ложная & Quot; является сильно перегруженным термином в тестировании & amp; Кружки TDD. См статью Мартина ФаулераИздевается не окурки, «Правильный» mock знает, какие значения он должен получить, и сообщает, когда он не получает того, что предполагалось; это позволяет вам выполнять тестирование взаимодействия вместо тестирования состояния - вы проверяете, что тестируемый класс передает правильные сообщения своим соавторам в правильной последовательности. Тестирование взаимодействия сильно отличается от обычного государственного тестирования и может быть трудно обдумать. Помня о том, что тестирование взаимодействия является предметом насмешек, они могут облегчить их понимание.

Полностью не согласен с Womp. Я автор оригинальной фиктивной статьи, и это не то, что мы имели в виду. Насмешки были разработаны как полезный инструмент, помогающий нам думать о том, как объекты взаимодействуют.
Вот почему я упомянул Mocks Aren't Stubs. Если все, что вы делаете с фреймворком mocking, - это тестирование состояния (что является вполне допустимым использованием для фреймворков mocking), то вы используете заглушки, а не (в более формальном смысле) макеты.
Полностью не согласен с последней строчкой. Интерактивное тестирование является побочным эффектом макетов фреймворков. Шутки долгое время создавались вручную с единственной целью государственного тестирования, не полагаясь на реальные ресурсы.
7

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

4

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

  1. Direct Output - result of a method call
  2. Internal Changes - changes to the class during a method call
  3. Indirect Output - code under test calls a different class

Основанное на состоянии тестирование - все о # 1 и # 2. # 1, глядя на результат, который дает вам метод. # 2 путем доступа к внутреннему состоянию объектов.

Это оставляет нас с # 3, для которого есть два пути, которые мы можем взять. Первый - с помощью Mock, а второй - с помощью Test Spy. Основное отличие состоит в том, что в Mock вы создаете ожидания перед выполнением тестируемого кода, а затем заставляете mock проверять их после, тогда как с помощью тестового шпиона вы выполняете тестируемый код и затем спрашиваете тестового шпиона, произошли ли определенные действия.

Итак, чтобы подвести итог всего этого ... когда вы думаете о тестировании того, что делает класс, если вам нужно протестировать косвенный вывод (то есть вызов другого класса), именно здесь Mocking вступает в игру.

3

Я также новичок в насмешках, но я попробую это сделать. По моему опыту, у насмешек есть два основных преимущества:

  • You can start working with objects before actually writing the implementation. You can define an interface and use mocking to work with the interface in unit tests or even code.
  • Mocking allows you to isolate the object under test in unit tests. With mock objects, you can completely control any objects that the object under test interacts with, therefore removing external dependencies from the test.
16

Цель насмешки состоит в том, чтобыisolate the class being tested из других классов.

Это полезно, когда класс:

  • connects to an external resource (FileSystem, DB, network ... )
  • is expensive to setup, or not yet available (hardware being developed)
  • slows down the execution of the unit tests
  • has a non-deterministic behavior
  • has (or is) a user interface

Это также облегчает тестирование на наличие ошибок, так как вы создаете свой фиктивный объект, чтобы он возвращал ошибку и выдает исключение ...

Макет может записать, как он был вызван (порядок вызовов функций, параметры), и это можно проверить с помощью теста. РЕДАКТИРОВАТЬ: Например: Метод, который вы тестируете, отправляет сообщение, такое как IPC. Метод фиктивного объекта может записывать, сколько раз он был вызван, параметр, который он получил (то есть сообщение, которое будет отправлено). Затем тест может опросить фиктивный объект и установить количество отправленных сообщений, содержание сообщения ... Аналогично, фиктивный объект может записывать методы, которые вызываются в строке журнала, а тест может извлекать эту строку и утверждать ее.

Do not abuse of mock objects: тестируйте поведение, а не реализацию, иначе модульные тесты будут слишком тесно связаны с кодом и хрупки (ломаются при рефакторинге).

Макет может быть закодирован вручную или сгенерированнасмешливая основа.

ОК, уточним это.
Филипп, спасибо за отличный ответ. Меня интересует последнее предложение: «Макет может записывать, как он был вызван (порядок вызовов функций, параметры), и это можно проверить с помощью теста». Это ново для меня, так как я новичок в юнит-тестировании / издевательстве. Что было бы примером этого? Это звучит полезно.
4

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

Я собирался сказать что-то подобное :)
Ну, пожалуйста, сделай. Мы можем объединиться против коллектива. У нас может быть свое, что это было «Uni-matrix 00 или 01». Приветствия.
Я знал, что Мать Гранди не справится. Но "Resitance бесполезен" для меня, когда дело доходит до этого вопроса
Это помогает нам неуверенным людям чувствовать себя лучше, указывая на абсолютную глупость других. Может быть, немного жалко признаться, что вы участвуете в нем, но это также чертовски весело.
0

Еще один ответ:

  • Stub = fake objects to be able to run your test without the entire real context

  • Mock = fake object to record the interaction of your component and verify theses interactions

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

Чтобы выйти за рамки основ, Mocks - это скорее поведенческая проверка, чем традиционная проверка состояния теста, при котором вы проверяете состояние вашего компонента после воздействия на него (Arrange, Act, Assert with Mocks, это больше Arrange, Act, Verify):

Проверка состояния Assert.AreEqual (valueExpected, mycomponent.Property); Поведенческая проверка: myMock.WasCalled (MyMethod);

0

Отличный пример насмешки в реальном времениБерт F

Unit Testing

Представьте себе модульное тестирование для этой системы:

cook <- waiter <- customer

Как правило, легко представить тестирование низкоуровневого компонента, такого какcook:

cook <- test driver

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

Труднее протестировать средний компонент, такой как официант, который использует поведение других компонентов. Наивный тестировщик может протестировать компонент официанта так же, как мы тестировали компонент готовки:

cook <- waiter <- test driver

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

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

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

    -----------------------
   |                       |
   v                       |
test cook <- waiter <- test driver

Здесь тест-повар «в сговоре» с тестовым водителем. В идеале тестируемая система разработана таким образом, чтобы тестируемый повар мог быть легко заменен (введенный) работать с официантом без изменения производственного кода (например, без изменения кода официанта).

Mock Objects

Теперь тест-повар (test double) может быть реализован разными способами:

  • a fake cook - a someone pretending to be a cook by using frozen dinners and a microwave,
  • a stub cook - a hot dog vendor that always gives you hot dogs no matter what you order, or
  • a mock cook - an undercover cop following a script pretending to be a cook in a sting operation.

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

    -----------------------
   |                       |
   v                       |
mock cook <- waiter <- test driver

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

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

Разговор о ложном тесте может выглядеть так:

test driver to mock cook: expect a hot dog order and give him this dummy hot dog in response

test driver (posing as customer) to waiter: I would like a hot dog please
waiter to mock cook: 1 hot dog please
mock cook to waiter: order up: 1 hot dog ready (gives dummy hot dog to waiter)
waiter to test driver: here is your hot dog (gives dummy hot dog to test driver)

test driver: TEST SUCCEEDED!

Но так как наш официант новичок, вот что может произойти:

test driver to mock cook: expect a hot dog order and give him this dummy hot dog in response

test driver (posing as customer) to waiter: I would like a hot dog please
waiter to mock cook: 1 hamburger please
mock cook stops the test: I was told to expect a hot dog order!

test driver notes the problem: TEST FAILED! - the waiter changed the order

или же

test driver to mock cook: expect a hot dog order and give him this dummy hot dog in response

test driver (posing as customer) to waiter: I would like a hot dog please
waiter to mock cook: 1 hot dog please
mock cook to waiter: order up: 1 hot dog ready (gives dummy hot dog to waiter)
waiter to test driver: here is your french fries (gives french fries from some other order to test driver)

test driver notes the unexpected french fries: TEST FAILED! the waiter gave back wrong dish

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

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

Похожие вопросы