Вообще, вопрос, поднятый в теме так и просится разбиения на два:
- Как тестировать методы с параметрами по умолчанию.
- Как тестировать методы со множеством параметров.
Как раз приведенный пример не в полной мере соответствует заголовку темы. Про тестирование параметров по умолчанию имеет смысл говорить в случаях, когда в логике метода есть разные ветви обработки параметров, полученных по умолчанию и параметров, указанных явно. Например, если есть что-то подобное:
X++:
if (prmIsDefault(...))
{
...
}
else
{
...
}
В данном методе ничего подобного нет, поэтому задача вырождается ко второму варианту.
А для второго варианта универсального подхода просто может и не быть, все зависит от задачи. Сам по себе факт наличия 11 параметров метода наталкивает на мысль от том, что с методом что-то не так. А если учесть, что в этом же классе есть публичный NEW с количеством параметров, превышающем десяток (по крайней мере в DAX2009 это так), то возникает вопрос все ли в порядке с самим классом.
Например (не претендую на истину в последней инстанции, это только мое личное мнение):
- Если решили делать рефакторинг, то вообще тест самого метода не нужен - покрываем тестами свои новшества. Правда тут возникает вопрос именно для этого класса - вдруг решили изменить NEW, то каким образом тестировать как это повлияет на весь класс в целом.
- Если нужно добавить новый параметр (хотя куда уж больше), то тестируем как будет работать метод когда новый параметр передаем, а когда не передаем. Возможно, что после просмотра покрытия, что-то добавим.
- Если нужна только "зеленая стрелка", то тут уже простор для фантазии огромный.
С чисто технической точки зрения тут можно определить только подход для ответа на вопрос
Цитата:
сколько тестирующих методов должно быть
В параметрах модуля тестирования можно задать как действовать при ошибке утверждений в одном тестирующем метод: продолжать выполнять другие методы или прервать тестирование. Для нескольких утверждений в одном методе, метод прерывается если хотя бы одно из утверждений ложно.
Соответственно:
- Если считаем, что метод не работает, если хотя бы одно из утверждений не выполняется, тогда все сочетания тестируем в одном методе.
- Если считаем, что некоторые сочетания параметров редкие и нужно проверять их отдельно, то такие сочетания выделяем в отдельный метод.
Опять же, после анализа покрытия вполне возможно, что подход изменим.
Вообще, unit тесты совсем не про то, что все работает правильно. Они проверяют работает ли метод (класс в целом) так как считает разработчик при проектировании этого метода/класса. Вполне нормальный вариант, что правильность (а не формальность) выносится уже на уровень функциональных тестов.