Применение CQRS - Требуется ли модульное тестирование тонкого слоя считывания?

Учитывая, что некоторые рекомендации по внедрению CQRS защищают довольно реалистичную реализацию запросов, таких как запросы ADO.NET непосредственно к базе данных (или, возможно, ORM на основе LINQ), является ошибкой попробовать и unit test их?

Интересно, действительно ли это необходимо?

Мои мысли по этому поводу:

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

В частности, я пытаюсь выполнить CQRS в приложении ASP.NET MVC, и мне интересно, нужно ли тестировать модульные методы моего контроллера или просто проверить модель домена.

Большое спасибо заранее.

Ответ 1

Я хотел бы согласиться с вами, что модульное тестирование такого кода не так полезно. Но есть некоторые возможности для некоторых полезных тестов.

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

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

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

Ответ 2

Как вы, наверное, уже знаете, что модульное тестирование меньше касается покрытия кода и предотвращения ошибок, чем для хорошего дизайна. Хотя я часто пропускаю тестирование обработчиков событий read-model, когда я спешу, не может быть никаких сомнений в том, что это, вероятно, должно быть сделано для всех причин, код должен быть TDD'd.

Я также не был модульным тестированием своих HTTP-действий (у меня нет контроллеров как таковых, так как я использую Nancy not.NET MVC).

Это точки интеграции и не имеют тенденций содержать много логики, поскольку большинство из них инкапсулировано в обработчики команд и модель домена.

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

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

Моя кишка говорит мне, что я все еще должен использовать TDD, но все еще очень слабо связан, и нет необходимости писать тесты. Если вам трудно писать тесты, которые могут указывать на запах кода в ваших контроллерах.

Ответ 3

По моему опыту, 90% -99% прочитанных вы будете делать, если создаете хорошую ненормированную модель чтения НЕ НЕ, чтобы иметь единичные тесты вокруг них.

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

Ответ 4

Способ, которым я видел что-то вроде этого протестированного устройства, состоит в том, чтобы unit test создать набор элементов в базе данных, запустить тесты модулей, а затем очистить созданные вещи.

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

Эти модульные тесты были очень полезны и обнаружили ряд ошибок в взаимодействии с базой данных.

Ответ 5

В одном моем приложении asp.net mvc я также применил sqrc. Но вместо sql и "запросов ADO.NET" или "Linq" мы используем базу данных документов (mongodb) и каждую базу данных прямого обновления для каждого инструмента или обработчика событий,

И я создал один тест для одного обработчика команд/событий. И после 100% модульного тестирования я знаю, что мой домен работает на 95% правильно. Но для действий/контроллеров/ui я применил тесты ui (используя selenium).

Таким образом, оба модульных теста для домена (обработчики команд/событий и прямые обновления базы данных) и ui проверяют его на "тесты интеграции".

Я думаю, что вы должны протестировать доменную часть, по крайней мере, потому что вся ваша логика инкапсулирована в обработчики команд/событий.

FYI: Я также начал разработку части домена сначала из фреймворка сущности, чем прямые обновления в базе данных с помощью хранимых процедур, но был действительно доволен базой документов. Я пробовал несколько разных баз документов, но mongodb выглядит лучше всего для меня.