Показать сообщение отдельно
Старый 26.03.2017, 17:02   #67  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,158 / 1286 (47) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Вообще, вопрос, поднятый в теме так и просится разбиения на два:
  1. Как тестировать методы с параметрами по умолчанию.
  2. Как тестировать методы со множеством параметров.
Как раз приведенный пример не в полной мере соответствует заголовку темы. Про тестирование параметров по умолчанию имеет смысл говорить в случаях, когда в логике метода есть разные ветви обработки параметров, полученных по умолчанию и параметров, указанных явно. Например, если есть что-то подобное:
X++:
if (prmIsDefault(...))
{
    ...
}
else
{
    ...
}
В данном методе ничего подобного нет, поэтому задача вырождается ко второму варианту.
А для второго варианта универсального подхода просто может и не быть, все зависит от задачи. Сам по себе факт наличия 11 параметров метода наталкивает на мысль от том, что с методом что-то не так. А если учесть, что в этом же классе есть публичный NEW с количеством параметров, превышающем десяток (по крайней мере в DAX2009 это так), то возникает вопрос все ли в порядке с самим классом.
Например (не претендую на истину в последней инстанции, это только мое личное мнение):
  • Если решили делать рефакторинг, то вообще тест самого метода не нужен - покрываем тестами свои новшества. Правда тут возникает вопрос именно для этого класса - вдруг решили изменить NEW, то каким образом тестировать как это повлияет на весь класс в целом.
  • Если нужно добавить новый параметр (хотя куда уж больше), то тестируем как будет работать метод когда новый параметр передаем, а когда не передаем. Возможно, что после просмотра покрытия, что-то добавим.
  • Если нужна только "зеленая стрелка", то тут уже простор для фантазии огромный.
С чисто технической точки зрения тут можно определить только подход для ответа на вопрос
Цитата:
сколько тестирующих методов должно быть
В параметрах модуля тестирования можно задать как действовать при ошибке утверждений в одном тестирующем метод: продолжать выполнять другие методы или прервать тестирование. Для нескольких утверждений в одном методе, метод прерывается если хотя бы одно из утверждений ложно.
Соответственно:
  • Если считаем, что метод не работает, если хотя бы одно из утверждений не выполняется, тогда все сочетания тестируем в одном методе.
  • Если считаем, что некоторые сочетания параметров редкие и нужно проверять их отдельно, то такие сочетания выделяем в отдельный метод.
Опять же, после анализа покрытия вполне возможно, что подход изменим.
Вообще, unit тесты совсем не про то, что все работает правильно. Они проверяют работает ли метод (класс в целом) так как считает разработчик при проектировании этого метода/класса. Вполне нормальный вариант, что правильность (а не формальность) выносится уже на уровень функциональных тестов.

Последний раз редактировалось Raven Melancholic; 26.03.2017 в 17:11. Причина: Орфографические и грамматические ошибки