Это не совсем сладкое место TDD - имейте в виду, что мотивация для TDD - это не тестирование (хотя это хороший побочный эффект), а дизайн , то есть создание кода легко изменить.
Частью ритуала TDD является частое выполнение тестов в течение цикла разработки; тесты, которые отвлекают от процесса разработки (например, отнимают много времени), выходят за пределы. Это не значит, что вы не можете пройти эти тесты; Одним из аргументов в пользу TDD является то, что он гарантирует наличие тестируемого кода. Но обычно вы не ожидаете запуска тестов, которые требуют значительного времени на настенных часах во время ритуала красный / зеленый / переработка.
Кроме того, тесты, которые тесно связаны с реализацией, являются настоящим тормозом, когда реализация нестабильна. Вы теряете доверие, когда тесты мешают изменить инкапсулированный дизайн в коде.
Иногда вы можете ввести требование наблюдаемости, чтобы из-за пределов системы можно было подсчитать, как часто вызывается критический раздел. И пока эта критическая секция используется системой, то, возможно, вы можете использовать подсчеты в качестве доказательства и оценить, масштабирует ли реализация то, что вы ожидаете.
В случае сортировки это может означать схему, в которой функция сравнения является настраиваемой зависимостью, а в тесте мы предоставляем реализацию, которая подсчитывает, как часто она вызывается.
Но это вводит некоторую связь - в этот момент вы измеряете, вызывается ли ваш метод или нет, не , дает ли испытуемый правильный ответ. В некоторых случаях это нормально. В других случаях это связано с соединением. Я не знаю ни одной простой эвристики, которую вы могли бы использовать, чтобы различать два случая, не пытаясь провести эксперимент и получить ожоги, когда происходит переподключение.