Что будет, если в тесте передать строку вместо числа?

Результат зависит от того, на каком уровне происходит проверка и как реализована тестируемая система.

1. На уровне модульного/интеграционного теста (разработка автотеста):

• Если функция ожидает число, а мы передаем строку "5", это потенциальный баг. Тест должен это выявить.
• В языках со строгой типизацией (TypeScript, Java) это приведет к ошибке компиляции, и тест даже не запустится.
• В JavaScript/Python это может привести к:
  • Неявному преобразованию типов (например, "5" * 2 = 10 в JS), и тест может пройти, скрыв проблему.
  • Ошибке времени выполнения (например, "abc" * 2 = NaN), и тест упадет.

Пример теста, который должен упасть:

// Функция, которую тестируем
function doubleNumber(num) {
  return num * 2;
}

// Неправильный тест (может пройти из-за неявного преобразования)
test('should double the number', () => {
  expect(doubleNumber("5")).toBe(10); // ПРОЙДЕТ! Это плохо.
});

// Правильный тест: проверяем тип или ожидаем ошибку
test('should throw error for string input', () => {
  expect(() => doubleNumber("abc")).toThrow();
  // Или используем TypeScript для статической проверки типов
});

2. На уровне тестирования UI/API (с точки зрения QA): Это классический позитивный тест-кейс для негативного сценария (negative testing).

• UI: Если в поле ввода, ожидающее число (например, "Количество"), ввести строку "abc", система должна:
  1. Или отобразить понятное сообщение об ошибке ("Пожалуйста, введите число").
  2. Или заблокировать ввод нечисловых символов (маска ввода).
• API: При отправке POST/PUT запроса с {"quantity": "five"} вместо {"quantity": 5}, API должен вернуть:
  • HTTP 400 Bad Request с описанием ошибки валидации.
  • Соответствующее сообщение в теле ответа, например: {"error": "Field 'quantity' must be a number."}

Вывод для QA-инженера: Тестирование передачи строки вместо числа — это обязательная проверка на устойчивость системы (robustness) и качество валидации входных данных. Автотесты должны покрывать такие сценарии, чтобы гарантировать, что система корректно обрабатывает некорректные данные, а не ломается или ведет себя непредсказуемо.