Comments 6
Для тестов пришел к аналогичному решению с гибкими фабриками, которые позволяют не передавать не релевантные для тест кейса данные.
От значений по умолчанию на уровне базы постарался отказаться. Профита от них не вижу, а логика в итоге размазывается между приложением и хранилищем.
Дефолтные значения для полей что могут быть не переданы в рамках нормальных сценариев работы приложения - стараюсь определять в конструкторе сущности.
Для случаев, когда как в примере из пункта #4, часть аргументов конструктора опциональны, но при этом обязывает наличие другого опционального параметра - делаю конструктор приватным, и создаю два публичных фабричных метода один из которых требует обязательную передачу обоих связанных аргументов, а второй не предполагает их передачи вовсе. Это если эти варианты вызываются при разных сценариях. Если комбинаций куда больше, либо язык не предусматривает таких конструкция - обьединяю связанные аргументы в одну структуру, даже если это требуется всего в одном месте
Чем не подойдет builder pattern? Кроме удобных мнемоник к аргументам (ведь named arguments не везде есть?) можно еще стандартные значения либо запретить, либо .withDate(c, m) / .withDateDefault(). Громоздко, да, но тут конструктор не красавец, как не глянь.
Тем что билдер обычно пытаются использовать там где поехало SRP и в один класс пытаются впихнуть то что надо бы делать разными. Но людям обычно лень размечать агрегаты так чтобы не было миллионов параметров. Конечно, ведь "проще" воткнуть ещё одну переменную и несколько условных операторов чтобы оно "просто работало" нежели делать отдельный класс под это, вот только это подходит только для тех случаев где future- proof не нужен.
Да и иммутабельные классы без методов для данных сильно проще и чище чем по заветам дяди боба.
Мне кажется тут стоит табличку в базе разделить на более мелкие, тогда и лишних данных гонять меньше будете и структура бд улучшиться и проще будет с табличками работать
Если не проставлять значения по умолчанию, придётся обрабатывать возможные исключения — так или иначе, от обработки неполноты данных не уйти. Вопрос лишь, насколько лояльным к такой неполноте должен быть наш продукт. Чем больше дефолтных значений, тем выше лояльность. Правда ваша в том, что стоит, наверное, на берегу решать, что мы можем задефолтить, а что должны выдавать в эксепшен, и применять это на всех уровнях.
кажется, что мы забираем часть ответственности клиента за чёткое понимание того, чего он хочет от нашей системы
Клиент хочет от системы только одно - сделать нужное действие. Вы для этого действия описываете контракт - что на входе, что на выходе. То есть вы задаете, что клиент должен отправить, а не он сам это решает.
Task1 - CreateService controller - Developer 1
Зачем эту задачу делить на 3 человек? При правильном подходе в контроллере находится только создание входного DTO, вызов сервиса и возврат ответа. Это делается за несколько минут.
Имя должно быть уникальным
Навскидку у него получилось с десяток различных тестов, что бы покрыть все варианты поведения UseCase
Если вы хотите протестировать валидацию DTO, тестировать надо конкретно валидацию DTO, а не весь юзкейс целиком. Вряд ли у вас поведение юзкейса зависит от конкретной ошибки валидации.
То есть для юнита "юзкейс" должно быть 2 юнит-теста - данные с ошибками валидации и данные без ошибок. Для второго случая может быть несколько тестов, в зависимости от бизнес-требований.
Но какой ценой? Теперь объекты приложения меняются для тестов.
Что мешает сделать специальный метод для тестов (не в классе CreateServiceDTO) с параметрами по умолчанию, который будет создавать CreateServiceDTO?
assert fake_service_repository.get_by_name("Name") == ServiceEntity(...)
Если тестируются правила валидации, то непонятно, почему проверяется сохранение сущности.
Для создания сущности в тестах можно сделать аналогичный метод.
Еще можно сделать тестовые данные массивом и проверять в цикле, а не делать отдельный юнит-тест для каждого варианта.
то в других случаях кажется, что это неправильное место для установки значений по умолчанию
Ну а зачем тогда так делать? У вас нет код-ревью?
Я хочу обсудить с вами такое положение дел, как повсеместное добавление аргументов по умолчанию.
Не знаю как в Питоне, но в других языках, насколько я знаю, так никто не делает.
Аргументы по умолчанию(мысли вслух)