Давайте возьмем ваше требование: «у человека всегда должно быть имя».Где мы могли бы начать?
Во-первых, нам нужна ясность.Я считаю, что когда вы говорите «должно всегда иметь имя», вы имеете в виду «никогда не должно иметь нулевую или пустую строку» в качестве имени.
То, что мы, вероятно, действительно имеем в виду здесь, это «когда человек хранится в нашей базе данных, его имя не может быть нулевым или пустым».Первая линия атаки будет заключаться в том, чтобы обеспечить это с помощью ограничения в вашей базе данных;однако ничто не защищает вас от мошеннических администраторов баз данных, снимающих это ограничение, поэтому вы можете проверить, что то, что вы считаете верным в системе, будет помечено неудачным тестом, если он изменится.Для этого вы должны написать тест вроде «когда мое приложение отправляет пользователя с нулевым именем для сохранения в БД, оно должно с треском провалиться».Это не модульный тест, это скорее интеграционный тест, и его сложнее написать, чем старый добрый модульный тест.
Тем не менее, это по-прежнему не распространяется на сценарий мошеннических администраторов баз данных, снимающих ограничение и непосредственно создающих записи с нулевыми именами.Другими словами, ваше приложение не может доверять верным данным, которые оно возвращает, поэтому возникает вопрос: как вы хотите, чтобы ваш домен обрабатывал возможность лиц с нулевыми именами?
Очень буквальный подход мог бы заключаться в том, чтобы принудить, что Person может быть создан только с ненулевым Именем, и бросает иначе.Это было бы легко для модульного тестирования и применения, но, вероятно, сделает разработку болезненной.Более приятный подход заключается в том, чтобы не иметь никаких ограничений на Person, но есть класс Validator, который может проверять Person на наличие нарушенных правил.Это более приемлемо, потому что теперь вы можете делать с Людью все, что пожелаете (в переносном смысле), и затем Проверять, находится ли этот Человек в Действительном состоянии.
Преимущество этого метода в том, что
1) очень легко тестируется: создание модульного теста для такого валидатора - дело простое,
2) обращение к мошенническим администраторам баз данныхпроблема: теперь вы можете проверять все, что исходит или выходит за пределы приложения, применяя Validator.
Итак, будучи ленивым разработчиком, я должен начать:Валидатор, потому что он решает мою проблему, и в то же время его гораздо проще тестировать, чем что-либо, связанное с данными.Другими словами, в общем, я стараюсь как можно больше придерживаться модульных тестов (то есть полностью в памяти) и иметь как можно больше своей бизнес-логики в коде / домене, потому что проще иметь все в одномместо, и легче проверить.