Здравствуйте, Codealot, Вы писали:

I>>У Фаулера нет указания, какие проверки.

C>Зато у тебя есть. Цитирую еще раз, для самых-самых сообразительных: "Любые внешние провеки, в любом количестве."

Ты выдрал фразу из контекста. Проверка, тест это твоё адекватное или не очень ожидание. Вроде бы понятно, что инженерия это именно про адекватные ожидания Как установить адекватность — используя требования. По моему это настолько очевидно, что упоминать лишний раз необязательно.
Тем не менее, см. пример в конце.

C>А любые — это может включать в себя и такие вещи, как микроскопические изменение в таймингах, например.

Попробуй прочесть целиком, а не только первую фразу.

Степень соответствия качеству никто не отменял. Я уже говорил, что 100% соответствие не существует. Ты продолжаешь это все игнорировать.

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

Всегда будут изменения это значит, что их всегда можно отыскать тем или иным способом. Эта часть понятна?

Тут ты обычно заканчиваешь читать и пишешь очередной опус.

1 См выше — степень соответствия качеству никогда не бывает 100%. Соответственно, граница рафакторинг-нерефакторинг определяется в т.ч. именно этой степенью соответствия.

2 Есть требования — фукнциональные и нефункциональные, в т.ч. неявные.

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

КАААААК! ЭТО НЕ РЕФАКТОРИНГ!!!!! ТЫ САМ СКАЗАЛ!!!!!!1111 ТЫ ВРЁШЬ!!!расрасрас

Как понять — из требований. Например, в код числодробилки иногда приходится узкое место оптимизировать, скажем, при помощью инлайна функции, колбека, компаратора, и тд.
Заинлайнил — есть нужный перформанс, работает. Не заинлайнил — нет перформанса, не работает.

Итого — микроскопические изменения отражены в требованиях? Если да, от ожидания адеватные. Если нет — то ожидания неадекватные.

Аналогичный пример с твоими таймингами. Ожидания адекватные? Тогда красный тест говорит о том, что изменения ломающие. Неадекватные — ничего не говорит.

Теперь добавляем сюда степень соответсвия. Самое главное — внятно обозначить её. Тогда получится не "любое изменение таймингов" а "изменение таймингов выше уровня х"