Как нам настроить сложные ситуации для тестов?

Question

В настоящее время я работаю над тем, что я бы назвал интеграционными тестами. Я хочу убедиться, что если вызывается служба WCF, она будет делать то, что я ожидаю.

Давайте рассмотрим очень простой сценарий. Предположим, у нас есть объект договора, который мы можем приостановить или снять. Теперь написать тест «отложено» довольно просто. Вы создаете экземпляр контракта и выполняете код, который помещает его в код.

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

var onHoldContract = new ContractBuilder (). PutOnHold (). Build ();

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

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

Любые другие варианты, которые я здесь пропускаю? или мнения о том, какой метод предпочтительнее и почему?

Answer 1

Mock Framework - хороший вариант для модульного тестирования. Но для того, что я понял, вы действительно делаете интеграцию на этом этапе, верно? Итак, вы называете свою службу WCF черным ящиком (с точки зрения клиента). Я предполагаю, что когда вы выполняете операцию «Удержание», вам необходимо выполнить некоторые действия с хранилищем (база данных, файлы XML и т. Д.).

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

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

Надеюсь, это поможет.

Answer 2

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

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

Вы не упомянули свой язык, но на всех основных языках доступны насмешливые рамки. Для .net, некоторые примеры были бы NMock из Rhino mocks . Для Java популярным является Mockito . Вы найдете множество других, если вы найдете Google на любом языке, который вы используете.