Тесты на существующий код

«Учебная функция принимает целое число единиц. С 1000 включительно действует скидка 10%; дробный итог округляется вниз. Для 999 ожидаю 999, для 1000 — 900, для 1001 — 900. Отрицательный вход вызывает ошибку». Передайте реализацию отдельно и попросите тесты по этому контракту. Условия примера учебные, их нельзя молча переносить в реальный денежный расчёт.

Внешний HTTP-запрос можно заменить управляемым ответом, чтобы проверить таймаут и отказ. Но подмена самой тестируемой функции доказывает лишь работу заглушки. Если цель — проверить SQL, ограничения или транзакцию, потребуется интеграционный тест с базой. Попросите явно перечислить границы подмен и назвать поведение, которое остаётся непроверенным в предложенном наборе тестов для вашего модуля.

Временно измените порог скидки с «не меньше» на «больше» в учебной копии: проверка суммы 1000 должна упасть. Аналогично попробуйте убрать валидацию отрицательного значения. Это проверка чувствительности набора, а не повод исправлять ожидаемый ответ под реализацию. После эксперимента верните код и прогоните тесты снова, сохранив лог исходного и изменённого поведения функции.

Начните с таблицы классов входов: ниже порога, на пороге, выше, недопустимое значение. Для сложной функции добавьте комбинации, влияющие на результат, вместо десятков похожих примеров. Укажите тестовый фреймворк и его версию. Чат подготовит код, но не подтвердит зелёный прогон в вашем проекте; запустите проверки и присылайте конкретный отказ с ожидаемым результатом.