Уважаемые знатоки, нормально ли будет, если интерактор выдаст модель ответа на запрос с ошибками в виде строк?
Вроде
{status: fail,
reason: not enough money}
Вроде как http коды ошибок

Поздравляю, это опровергает весь TQM и прочее "японское чудо".

Каким образом опровергает?

TQM утверждает обратное - контроль качества отдельных компонентов повышает качество изделия.

Никакого противоречия
Качество компонентов не проверяется юнитами - только качество "изолированности компонентов"

условно у тебя могут быть качественные компоненты которые вместе не работают. Внутреннее и внешнее качество. Потому пирамидки все делают всякие, или трафеи (фронтендщики в основном)

Ну и вроде как основная идея TQM в том что бы "контроль качества" вводить на более ранних этапах и за счет этого уменьшать сколько брак на линии проводит. Но тут я не шарю. Сча это всякие Shift Left похожие штуки называют.

Модульные тесты - это первая линия обороны контроля качества.

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

модульные тесты - это "внутреннее качество", дизайн системы, вот это все. Это важно, просто важно понимать что тесты в целом не про "поиск багов". Это поиск регрессий для известных кейсов. С херовым качеством внутреннего дизайна количество "кейсов" будет проблема которую ты в одной из своих статей описывал - аля комбинаторика все дела.

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

Но без тестов приемочных которые проверяют компоненты в сборе ты не сможешь ответить на вопрос "а фича вообще работает?".

Нужны и те и те.

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

тут важно объяснять за счет чего это быстрее. за счет того что во время написания тестов для сложной логики ты эту логику формализуешь и тебе не приходится держать все кейсы в голове. И в случае с TDD это быстрее именно за счет того что формализация + дизайн происходят на той же стадии что и тесты, что обычно занимает меньше времени нежели сначала подумать/дизайн потом реализация потом тесты.

А тому кто тесты не пишет это крайне сложно обьяснить. Мне некоторое время назад тоже сложно было бы понять. Это прочувствовать надо.

сложно потому что смысл TDD не в тестах) Это как "смысл ООП не в объектах")

И ссе это превращается в довольно увлекательную игру

Типа квест

+. ты проверил ее тестами и не боишься, а работает оно или нет. но очень маленький класс задач под это подходит.

например для регулярок идеальный кейс

класс задач достаточно большой. В целом Кент Бэк про TDD как подход управлением страхом и говорит. Ты регулируешь длину итерации red-green-refactoring до тех пор пока ты уверен в своих действиях.

Есть люди которым это просто не нужно, они в состоянии в голове большие системы крутить. Есть люди у которых крэдо "слабоумие и отвага".