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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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