Скорее всего, вы получили 65 миллиардов тестов, рассчитав все возможные комбинации входов в тестируемую систему или вычислив цикломатическую сложность и предполагая, что тест должен быть написан для каждого из этих уникальных путей выполнения.
Это не то, как пишутся реальные тесты, потому что, как указывали другие авторы и комментаторы, техническая мощность, необходимая для выполнения 65 миллиардовтесты ошеломляют. Это похоже на написание теста, в котором используется метод добавления двух целых чисел путем подключения каждой возможной перестановки двух 32-битных значений и проверки результата. Это полное безумие. Вы должны нарисовать линию и определить подмножество всех возможных тестовых случаев, которые между ними будут гарантировать, что система будет вести себя так, как ожидается, во всем диапазоне входных данных. Например. вы тестируете добавление нескольких «обычных» чисел, вы тестируете несколько сценариев с отрицательными числами, вы проверяете технические ограничения, такие как сценарии переполнения, и тестируете любые сценарии, которые могут привести к ошибке. Как уже упоминалось, эти различные типы тестов осуществляют "классы эквивалентности"; они позволяют вам взять репрезентативную выборку возможных входных данных, наряду с любыми известными «выбросами»,
Рассмотрим один из основных кодовых катов, генератор римских цифр. Задача, которая должна выполняться с использованием методов TDD в стиле «додзё», состоит в том, чтобы написать функцию, которая может принимать любое число от 1 до 3000 и производить правильную римскую цифру для этого числового значения.
Вы не решаете эту проблему, написав 3000 модульных тестов, по одному, и проходя их по очереди. Это безумие; упражнение обычно занимает от одного до двух часов, и вы проведете там несколько дней, проверяя каждое отдельное значение. Вместо этого вы становитесь умным. Вы начинаете с самого простого базового случая (1 == «I»), реализуете его, используя стратегию «наименьшего кода» ( return "I";), а затем ищите, как ваш код будет вести себя неправильно в другом ожидаемом сценарии (2 == » II "). Промыть и повторить; скорее всего, вы заменили свою первоначальную реализацию чем-то, что повторяет символ «I» так часто, как это необходимо (например return new String('I',number);). Это, очевидно, пройдет испытание на III, так что вы не беспокойтесь; вместо этого вы пишете тест для 4 == "IV", который, как вы знаете, выиграл в текущей реализации '
Или, в более аналитическом стиле, вы изучаете каждое условное решение, которое принимается кодом (или должно быть), и пишете тест, предназначенный для ввода кода для каждого возможного результата каждого решения. Если у вас есть 5 операторов if (каждый из которых имеет ветви true и false), каждый из которых полностью независим от другого, вы кодируете 10 тестов, а не 32. Каждый тест будет разработан, чтобы утверждать две вещи относительно конкретного возможного решения; сначала, что правильное решение принято, и затем, что код, введенный при условии, что условие является правильным. Вы не пишете тест для каждой возможной перестановки независимых решений. Если решения являются зависимыми, то вам нужно проверить больше из них в комбинации, но таких комбинаций меньше, потому что некоторые решения принимаются только тогда, когда другое решение имело определенный результат.