TDD, DDD и инкапсуляция

Question

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

Однако многие из образцов TDD, которые я видел, вызывают метод объекта домена, а затем проверяют свойства объекта, чтобы обеспечить корректное выполнение поведения.

С другой стороны, несколько уважаемых людей в отрасли (Грег Янг наиболее заметно с его переговорами о CQRS) защищают полностью инкапсулирование каждого объекта домена, удаляя все «геттеры».

Мой вопрос заключается в следующем: как проверить функциональность объекта домена, если ему запрещено получать его состояние?

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

Answer 1

Что вы описываете, это подтверждение состояния, в котором вы указываете состояние объекта домена. Существует ветвь TDD, которая называется верификацией поведения, которая использует объекты Mock.

Проверка поведения позволяет указать, какие методы следует вызывать, а если хотите, какие методы не вызывают.

За дополнительной информацией обратитесь к этой статье Мартина Фаулера: Mocks Aren't Stubs.

Answer 2

Пара вещей.

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

Во-вторых, архитектура OO oldschool пытается сделать программное обеспечение безопасным, используя языковые гарантии, чтобы предотвратить доступ к вещам. Архитектура TDD делает программное обеспечение более надежным, написав тесты, которые проверяют, что на самом деле делает код, уделяя меньше внимания использованию языковых конструкций, чтобы гарантировать, что программа не делает.

Последнее, что проверка свойства не является единственным способом проверки кода, сделал то, что он должен был делать. В книге xUnit Design Patterns описаны другие подходы здесь: http://xunitpatterns.com/Result%20Verification%20Patterns.html

Answer 3

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

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

Сделайте то, что лучше всего подходит для вас.

Answer 4

Я вызываю общедоступные методы ввода системы (т. Е. Вставляю входные данные в систему), а затем получаю (и утверждаю) вывод системы.Я не тестирую внутреннее состояние системы, а скорее ее общедоступное/видимое поведение: Should one test internal implementation, or only test public behaviour?

Answer 5

То, что вы упомянули, называется государственным тестированием. Также проводится тестирование поведения. Методы, используемые для этого: Инъекция зависимостей, Инверсия управления и Сфокусировка:

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

Существует множество Mocking Framework, которые автоматизируют создание имитирующего объекта, динамически генерируя классы, реализующие данный интерфейс. Наиболее популярными являются Rhino.Mocks и Moq.

Answer 6

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

Это, как говорится, я борюсь с тем же вопросом ... как вы можете протестировать объект домена только для записи? Вот мой текущий план: я подумываю о том, чтобы мой объект домена загорелся в домене, назвав «Эти свойства изменены», и в своем модульном тесте я зарегистрирую его, прежде чем отправить «EditCommand». Проверьте сообщение Уди Дахана о событиях домена here, а также см. what Eric Evans says about Domain Events.

Answer 7

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

1. Using Mocks and Tests to Design Role-Based Objects
2. Mock Roles, Not Objects

Answer 8

OK, этот ответ один год слишком поздно ;-)

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

например. Если вы хотите проверить, звоните ли вы: customer.Rename («Foo») приводит к правильному поведению.

Вместо проверки, если customer.Name равно "foo", вы скорее проверяете, есть ли ожидаемое событие CustomerRename со значением "Foo" в вашем ожидающем хранилище событий. (в вашем уроне или в списке событий сущности в зависимости от реализации)