Почему нам нужны платформы насмешки?

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

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

Иногда при работе со сторонними библиотеками или даже с некоторыми аспектами платформы .NET чрезвычайно сложно написать тесты для некоторых ситуаций - например, HttpContext или Объект Sharepoint. Создание имитирующих объектов для них может стать очень обременительным, поэтому фреймворки имитаций позаботятся об основах, чтобы мы могли сосредоточиться на том, что делает наши приложения уникальными.

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

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

Посмотрите Rhino Mocks для примера о том, насколько мощным может быть фреймворк для имитации.

Мок-объекты заменяют любые большие / сложные / внешние объекты, к которым вашему коду необходим доступ для выполнения.

Они полезны по нескольким причинам:

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

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

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

Единственная причина использовать имитирующая библиотека состоит в том, что она упрощает имитацию.

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

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

Конечно, вы можете смоделировать свои зависимости вручную, но с помощью фреймворка это избавляет от утомительной работы. Также стоит изучить обычно доступные утверждения.

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

 //mock creation
 List mockedList = mock(List.class);

 //using mock object
 mockedList.add("one");
 mockedList.clear();

 //verification
 verify(mockedList).add("one");
 verify(mockedList).clear();

 //stubbing using built-in anyInt() argument matcher
 when(mockedList.get(anyInt())).thenReturn("element");

 //stubbing using hamcrest (let's say isValid() returns your own hamcrest matcher):
 when(mockedList.contains(argThat(isValid()))).thenReturn("element");

 //following prints "element"
 System.out.println(mockedList.get(999));

. Хотя это надуманный пример, если вы замените List.class на MyComplex.class , тогда ценность фреймворка для фиксации станет очевидно. Вы можете написать свое собственное или обойтись без него, но зачем вам идти этим путем.

Я сначала понял, зачем мне нужен фреймворк, когда сравнил написание тестовых дублей вручную для набора модульных тестов (каждый тест требовал немного другого поведения, поэтому я создавал подклассы базового поддельный тип для каждого теста) с использованием чего-то вроде RhinoMocks или Moq для выполнения той же работы.

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

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

Например, если у меня есть класс A, содержащий бизнес-правила и логику, которые я хочу протестировать, но этот класс A зависит от классов доступа к данным, других бизнес-классов, даже классов u / i и т. Д., Эти другие классы может быть смоделирован для выполнения определенным образом (или вообще никаким образом в случае слабого имитационного поведения) для проверки логики в вашем классе A на основе всех мыслимых способов, которыми эти другие классы предположительно могут вести себя в производственной среде.

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

public bool IsOrderOnHold(int orderNumber) {}

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