Модульное тестирование атрибутов доменных моделей в системе CQRS - PullRequest
Новая
       30

Модульное тестирование атрибутов доменных моделей в системе CQRS

0 голосов
/ 14 января 2019

Мне нужны мысли других о конкретном сценарии, касающемся атрибутов модели домена (сущностей, VO и т. Д.) В приложении, использующем CQRS.

Представьте себе упрощенный пример продукта (объекта) с названием продукта (VO). 

class Product
private ProductName productName

Продукт имеет несколько основных защитных ограждений и инвариантов:

  • Имя продукта не может содержать более 100 символов (применяется в VO).
  • Продукт должен иметь имя продукта (применяется в сущности с именем продукта, установленным в конструкторе, чтобы оно всегда действовало).

Я могу провести модульное тестирование сущности «Продукт» и «Имя продукта», чтобы убедиться в их правильном применении и возникновении ошибок и исключений. Легко.

Мой вопрос касается модульного тестирования «счастливого пути» - чтобы имя продукта было задано успешно при первоначальной разработке продукта.

В системе, не относящейся к CQRS, у меня должно быть открытое свойство только для чтения или метод получения в названии продукта, чтобы его можно было извлечь для создания отчетов, отображения или заполнения DTO. Затем я могу выполнить юнит-тест с этим свойством.

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

Для модульного тестирования успешного создания продукта, хотя мне нужно сделать «Имя продукта» открытым для чтения свойством, чтобы проверить его, но, кажется, неправильно делать это только для выполнения модульного теста. Без модульного теста название продукта может оставаться закрытым, и все будет работать по мере необходимости.

Хотите знать, сталкивался ли кто-нибудь с подобным сценарием для модульного тестирования -> Где атрибут, который в основном предназначен для презентаций (хотя, очевидно, очень важен ... Я не ожидал бы, что пользователи будут пытаться работать с Продуктами только по номерам деталей). или идентификаторы) проверяется?

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

1 Ответ

0 голосов
/ 14 января 2019

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

Как данные поступают из вашей доменной модели в ваше постоянное хранилище? Как данные попадают из вашей модели записи в вашу модель чтения?

Где-то в вашей кодовой базе у вас есть либо функция, которая принимает Product в качестве ввода и возвращает не зависящее от домена представление его (byte [], или JSON, или что угодно), или у вас есть метод, который принимает в качестве аргументов Product и обратный вызов, который принимает не зависящее от домена представление.

Он может быть явным или неявным (магия ORM?), Но он где-то там будет - доменные сущности "только для записи" не очень интересны.

Ваши тесты должны использовать тот же механизм.

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

...