Зелёные тесты могут соседствовать с очередью задач, которые способен выполнить только автор модуля.

Допустим, нужно добавить правило скидки для оптового клиента. Другой инженер понял требование, получил вводный разбор, но не может найти, где принимается решение. Расчёт разбросан по обработчику запроса и нескольким сервисам. Каждый следующий шаг требует объяснения автора.

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

Сначала нужно дать контекст. Такая проверка не должна превращаться в экзамен на мгновенное понимание чужого кода.

Незнакомый термин предметной области может указывать на пробел во вводном объяснении. А необходимость собирать одно правило из несвязанных мест даёт конкретную цель для рефакторинга.

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

Количество новых классов не доказывает улучшение. Практический результат виден, когда обычная правка перестаёт ждать одного человека.