Модульное тестирование перевода ответа WCF объекту домена

Question

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

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

Я думал о том, как упростить создание ответов и сделать мои unittests более чистыми.

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

Про этот метод заключается в том, что unittests станет намного меньше и легче создать. Но обновление файла/элемента будет сложнее. Или, по крайней мере, это то, что я думаю.

У кого-нибудь есть несколько мыслей или разные варианты для создания этого здания ответа?

Answer 1

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

var mc = fixture.Build<MyResponseClass>() 
    .With(x => x.SomeProperty, "SomeValue") 
    .CreateAnonymous(); 

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

Answer 2

Я думаю, что Lloyd означает, что вы берете свой текущий код, который отвечает за создание объектов ответа и упаковывает их в отдельную * .dll, так что это просто API или библиотека, которую вы затем можете вызвать из своего модульные тесты. Таким образом, ваши модульные тесты станут намного проще. Еще одно преимущество этого подхода состоит в том, что вы могли бы построить два API: один из которых создавал поддельные объекты, а другой - запрашивал реальный сервис. Используя интерфейс, вы можете легко переключить API через настройку конфигурации. Вы также можете попробовать использовать насмешливую инфраструктуру, такую ​​как MoQ или smth. если это имеет смысл в вашем случае.

Answer 3

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

Если вы следуете этому образцу, вы можете должны быть в состоянии идентифицировать каждый тестовый случай, как один из следующих:

основные случаи

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

Отклонение Случаи

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

Это, по сути, сводится к DRY, так как ваши основные случаи определяют вещи, которые являются «общими» среди ваших тестов, поэтому вы не тратите 200 строк на установление значений. Большинство ваших конкретных входных тестов должны быть представимы «Так же, как < тест > но с < отклонения >», так что вы должны написать их в качестве таковых.