Но вообще обычно тесты достаточно хорошие, чтобы поймать все очевидно плохие решения

Нет это условие в начале, ниже рабочий код

Тесты закрытые, если что

И зачем так делать? Чтобы получить реджект на ручной проверке?

И есть ли хоть одна причина так делать?

Какая разница есть или нет, я лишь указал на то что нельзя такое решить некими наборами тестовых данных

Ну в общем случае задача проверки правильности решения - это нерешенная задача.

Глаза тут не панацея и помогают только в простейших задачах

Почему же, миллиард входных параметров и проверка результата

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

Задача тестовых данных не в том, чтобы определить, идеален ли твой код и всегда ли он работает.

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

Если ты туда вкрутишь специально падение на редком кейсе – поздравляю, ты обманул тесты, но в ту сторону, которая тебе не нужна.
Ну и чего ты добился?

И, опять же – при необходимости бывает ручная проверка после прохождения всех тестов.

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

Да, это правда

Не совсем, имея АСТ кода как параметр можно автоматически выявить классы эквивалентности

Тогда мое условие которое должно не пройти сразу будет выявлено

Только для одинаковых по сути решений.
Нельзя сказать, что A и B эквивалентны или нет в общем случае

Приведи ка пример когда это нельзя доказать

Задача определения эквивалентности двух МТ неразрешима, как и проблема останова.

Я вообще то к тому и вел что гарантировать решение можно только перебором и если допустим поставить delay 0.98 то проверка затянется на века...

МТ это что такое?

Машина Тьюринга, формализация алгоритмов.