TDD, DDD и инкапсуляция
Выбранный ответ только наполовину прав. Вы должны сравнить массивы в обоих направлениях, чтобы получить полный ответ.
const ids_exist = [
'1234',
'5678',
'abcd',
]
const ids_new = [
'1234',
'5678',
'efjk',
'9999',
]
function __uniq_Filter (__array_1, __array_2) {
const one_not_in_two = __array_1.filter(function (obj) {
return __array_2.indexOf(obj) == -1
})
const two_not_in_one = __array_2.filter(function (obj) {
return __array_1.indexOf(obj) == -1
})
return one_not_in_two.concat(two_not_in_one)
}
let uniq_filter = __uniq_Filter(ids_exist, ids_new)
console.log('uniq_filter', uniq_filter) // => [ 'abcd', 'efjk', '9999' ]
8 ответов
То, что вы описываете, это проверка состояния , при которой вы утверждаете состояние объекта домена. Существует ветвь TDD, которая называется проверка поведения , которая использует Mock-объекты.
Проверка поведения позволяет вам указать, какие методы должны вызываться и, если хотите, какие методы не вызываются.
Подробнее читайте в этой статье Мартина Фаулера: Моки не являются заглушками .
Если вы действительно собираетесь запретить извлечение состояния, тогда вы будете ограничены поведенческим тестированием, возможно, с помощью фреймворка для фиксации, такого как TypeMock, который может отслеживать поведение вашего объекта. Если вы умеете делать чистый BDD, то теоретически вы можете утверждать правильность всей вашей системы только по тому, как она ведет себя.
На практике я обнаружил, что BDD во многих случаях более хрупок, чем просто с сохранением состояния. тестирование. Хотя некоторые люди могут требовать определенной теории, она работает, только если работает для вас. Тестирование на основе состояний по-прежнему составляет 90% всех создаваемых нами модульных тестов, и мы хорошо знаем о BDD в нашей команде.
Я вызываю общедоступные методы ввода системы (т. Е. Отправляю входные данные в систему), а затем получаю (и утверждаю) вывод системы. Я тестирую не внутреннее состояние системы, а ее общедоступное / видимое поведение: Следует ли тестировать внутреннюю реализацию или проверять только общедоступное поведение?
То, что вы упомянули, называется тестированием состояния . Также есть тестирование поведения. Для этого используются следующие методы: внедрение зависимостей, инверсия управления и имитация:
Все побочные эффекты вашего класса реализуются как вызовы методов на его «зависимостях», т. Е. объекты, поставляемые извне, обычно в конструкторе. Затем в своем модульном тесте вы предоставляете поддельный объект вместо реального. Поддельный объект может запомнить, был ли вызван его определенный метод, и это то, что вы утверждаете в своем тесте.
Существует ряд Mocking Framework, которые автоматизируют создание фиктивных объектов путем динамического создания классов, реализующих данный интерфейс. Наиболее популярны Rhino.Mocks и Moq.
Пара вещей.
Во-первых, когда вы делаете такие вещи, как TDD, чтобы проверяемый код, вы получите меньший класс. Если у вас есть класс с множеством частных свойств, которые вы не можете проверить, есть большая вероятность, что его можно разбить на несколько классов и сделать более тестируемым.
Во-вторых, ОО-архитектура старой школы пытается сделать программное обеспечение безопасным, используя языковые средства защиты для предотвращать доступ к вещам. Архитектура TDD делает программное обеспечение более надежным за счет написания тестов, которые проверяют, что код действительно делает, уделяя меньше внимания использованию языковых конструкций, чтобы убедиться, что программа не делает.
Наконец, проверка свойства - не единственный способ проверки код сделал то, что должен был делать. В книге «Шаблоны проектирования xUnit» описаны другие подходы здесь: http://xunitpatterns.com/Result%20Verification%20Patterns.html
Привет, Джастин, как и ты, я недавно думал о добавлении геттеров в мой объект домена только для записи ради модульного тестирования, но теперь я убежден Я ошибался. Если предположить, что вы в первую очередь подкупили идею домена только для записи, то, если у вас вообще есть геттеры, вы напрашиваетесь на проблемы. Принцип домена только для записи требует, чтобы вы запускали событие из своего объекта домена или читали из проекции, которую написал ваш объект домена, или что-то в этом роде. Как только вы открываете геттеры, вы начинаете раскрывать «форму» объекта, и, как говорит Грег Янг, «объекты домена имеют поведение, а не форму».
При этом я не могу ответить на ваш вопрос ... как выполнить модульное тестирование объекта домена только для записи? Вот мой текущий план: я подумываю о том, чтобы мой объект домена запускал событие домена с сообщением «Эти свойства изменены», и в моем модульном тесте я зарегистрируюсь для него, прежде чем отправлять команду «EditCommand». Прочтите сообщение Уди Дахана о событиях домена здесь , а также посмотрите , что Эрик Эванс говорит о событиях домена .
Мне было интересно то же самое пока я наконец не наткнулся на следующие документы. Я обнаружил, что они являются отличными учебниками по выполнению проверки поведения, особенно первый из них, дающий мне несколько «ага-моментов»:
ОК, этот ответ запоздал на год ;-)
Но когда вы хотите протестировать модели CQRS, вы можете делать утверждения на запущенных событиях домена вместо утверждений на состоянии сущности.
например. если вы хотите проверить, приводит ли вызов : customer.Rename("Foo") к правильному поведению.
Вместо того чтобы проверять, равно ли customer.Name "foo", вы лучше проверите, есть ли в вашем хранилище событий ожидающее событие CustomerRename со значением "Foo". (в вашем uow или в вашем списке событий сущности, в зависимости от реализации)