Это была обувь на пару размеров ниже)

Второй подход тоже не требует править тесты, если функционал добавляется.

Если модифицируется, то, естественно, тесты на модифицированные классы надо менять, так как контракты у этих классов поменялись.

Поэтому второй подход очень нетерпелив к нарушению OCP.

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

Это популярное заблуждение

Может быть, но одно дело когда бизнесу 20 лет, другое дело когда требования формирует менструальная бывшая учительница, которая получает их от директора бегом по утрам

И в итоге на 80% фич - я не то имела ввиду, вы не так поняли

А второй подход лучше? Я не вижу, чем

В целом вот эти темы типа classicist vs mockist рассматривать надо только в разрезе tdd. Разница в том как происходит процесс проектирования взаимодействия между зависимостями. Мол в случае с classicist ты если понял что нужна зависимость сначала реализуешь ее, а потом уже то для чего она нужна. Mockist же спроектирует взаимодействие через моки, поймет контракт и тогда уже будет делать саму зависимость.

Тут нет лучше или хуже. Есть движение сверху вниз или из середины вверх грубо говоря. Подходы mockist сильно чувствительны к утечке деталей и декомпозиции и потому кто то говорит что "это помогает".

Когда у тебя реализация а потом тесты в этой дихотомии нет смысла. У тебя нет проектирования через тесты и скорее всего будут проблемы с зависимостями.

Но в любом случае оба подхода считают дурным тоном если рефакторинг реализации ломает тест.

Совершенно другое качество кода в продакшене.

Второй подход больше не про тесты, а про тестируемый код. Все вот эти DI, OCP, разделение инициализации и бизнес-логики - это про  тестируемый код. И тесты в этом походе - лишь маленькая часть.

Для меня тдд сложно, т.к большинство требований/нюансов выясняются в результате реализации. И даже если заставить себя вначале написать тесты под реализацию, ничего общего с итоговым результатом это иметь не будет

Есть ряд неочевидных вещей (например смешание понятий мок или стаб), что если ты стабишь метод зависимости надо описывать поведение всех методов и что бы контракт соблюдался. Что в целом зависимостей стоит избегать и перераспределять логику

Уменьшай длину итерации между тестом и реализацией. Не "надо написать 10 тест кейсов сначала а потом реализацию" а двигайся маленькими шагами

Есть ещё трабл что с опытом в простых тестах не видишь смысла и в целом далеко не все хочется покрывать. Да и потом e2e это не отменяет все

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

ЗАказчик визуал, как заставить его смотреть тесты?))

Спасибо, сам давно об этом думаю, основные проблемы всплывают за день до демо

причем обычно этих проблем еще на один спринт, до этого всем пох было

Вайрфреймы, мокапы, прототипы, gherkin сценарии... Много способов дёшево собрать фидбэк

Мы в целом умеем быстро код писать, научились за 50 лет, а вот требования быстро фильтровать и приоритизировать все ещё проблема

Вот это интересно, буду копать, так работать это выгорание всей команды и геморой