assume(a>=1);
assume(b>=2);
is(a + b >= 3);

unknown

???

Тесты на всё

Проверить, всегда ли условие будет истинно при указанных входных параметрах, задаваемых в виде диапазонов и/или фиксированных значений.

Неслабое такое требование. Написание теста на ряд различных входных параметров это норма, но проверить диапазон это уже перебор. В таком случае правильный тест, который действительно тест, а не автоматическая логическая выводилка, должен содержать все варианты входных условий (сколько там битов используется для хранения float?) и все соответствующие им правильные ответы.

Найти диапазон значений какого-то параметра условия при которых условие будет всегда истинно (или ложно).

Это вообще не задача теста. Тест всегда имеет бинарный выход, либо пройден, либо нет.

Модульные тесты модульны

Перед попейсателем юнит тестов стоят задачи:

Модульные тесты должны писать разработчики кода модулей, а не отдельный человек. Вот приёмочные и интеграционные тесты, это уже другое.

ОК, на в тестируемой системе есть проверка

a < (b + c - d)

я должен всегда передавать фиксированные значения тестируемой системе или таки рандомные из указанного диапазона? Какой тогда use case у этой функции?

Когда тестируемой системе нужно передавать случайное значение из диапазона, а не фиксированное значение?

это легаси модуль

Одним из способов получения хорошего покрытия тестами без длительного анализа поведения и генерации тестовых условий является использование различных значений при каждом запуске тестов. Одним из решений на пути к этой цели является использование случайных сгенерированных значений (Random Generated Value). Хотя такой подход может показаться хорошей идеей, тесты становятся неопределенными, что значительно усложняет отладку неудачно завершившихся тестов.

В идеальном случае при неудачном завершении теста должна иметься возможность повторить неудачное завершение. Для этого случайное сгенерированное значение (Random Generated Value) можно занести в журнал работы теста и показать вместе с отчетом о неудачном завершении. После этого тест необходимо вынудить еще раз воспользоваться этим значением, пока разработчик занимается отладкой.

В большинстве случаев затраченные усилия перевешивают потенциальную выгоду. Конечно,если это действительно нужно, данный способ применять необходимо.

масло маслянное. Расплывчато даже у Месароша.

Предсказуемость

Когда тестируемой системе нужно передавать случайное значение из диапазона, а не фиксированное значение?

Когда хотите получить тесты с непредсказуемым поведением.

э.. а фейковые строки разве влияют на предсказуемость прохождения тестов?

Пока тестировалка не отсохнет

Смотрите, написание тестов и поиск таких условий при которых он заваливается это разные задачи.

Правильно написанный тест должен стабильно проходится, либо так же стабильно заваливаться.

А вот поиск таких значений входных параметров при которых тест падает может быть отдельной увлекательной задачей. Можно пытаться решить её перебором, можно пытаться использовать использовать генератор случайных чисел, можно пытаться анализировать функцию, искать сбойные значения в тех местах где левая и правая части неравенства наиболее близки. Результаты этого писка можно потом использовать в тестировании, но это результат решения отдельной задачи.

ОК, предположим, что в определенном тест кейсе поведение тестируемой системы не зависит от значения определенного аргумента. Он имеет тип число. Что ты будешь туда передавать? Точное значение (Literal Value)? Ты не сможешь там применить паттерн «описательное значение» (Self-Describing Value) - он только для строк работает.

таким образом, ты предлагаешь использовать только ФИСКИРОВАННЫЕ значения, а не сгенерированные из указанного диапазона?

Т.е. грубо говоря, я усложняю задачу байдой с диапазонами?

Итак, если нужно тестировать условие freeSpace > fileSize, то нужно ВСЕГДА задавать в Arrange-фазе фиксированные а и б, и обязательно сделав их обе Symbolic Constant с именами, характеризующими тот «диапазон», в который они попали?

Пример для проверки ложности условия:

Инициализация входных данных для тестируемой системы: notEnoughFreeSpace = 0 fileTooBig = 10

Передача парамтеров в тестируемую систему: notEnoughFreeSpace -> freeSpace fileTooBig -> fileSize

Если мы передадим просто 0, 10 то будет не совсем ясно, какое значение для тестируемой системы имею переданные параметры.

ОК?

Я не понимат

Он имеет тип число. Что ты будешь туда передавать?

Число.

Точное значение (Literal Value)?

Ну, какое-то значение передам. В разных тестах передам разные значения

Не скажу за js, но в C если функция должна особым образом реагировать на какие-то константы, которые определены макросами (#define SPECIAL_VALUE 42), то в модульных тестах должно передаваться SPECIAL_VALUE (потому что это значение там известно), а вот в интеграционных уже 42.

И вообще, я не уверен, что понял вопрос.

Другая задача

Т.е. грубо говоря, я усложняю задачу байдой с диапазонами?

Не усложняешь, а ставишь другую задачу.

ОК, так мне до сих не понятен use case для генератора фейковых данных из заданного диапазона.

Зло встречается

ОК, так мне до сих не понятен use case для генератора фейковых данных из заданного диапазона.

Написание плохих тестов.

Кто решает такие задачи лучше?

Проприетарная Mathematica.

Ты хочешь очень странного, но есть отличный Axiom, есть Maxima, есть XCAS

ОК.

\me начал изучать книжку Introduction to Combinatorial Testing

там это все есть, да.