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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

Корпус для сердечника

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

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

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

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

Answer 3

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