Как правильно выполнять unit-тестирования методов с параметрами по умолчанию на ваш взгляд?

[VORP]

Надо протестировать что каждый из параметров отрабатывает правильно, то есть его изменения приводят к ожидаемому результату, а потом написать интеграционный тест где задать все параметры, убедившись что они взаимодействуют правильно. Было на тренинге по Acceptance Tests.
На самом деле тут (я имею ввиду Аксапту вообще) проблема другая, а именно что одним из параметров является состояние системы. Положим, для простоты что считывается значение из LedgerParameters, а дальше исполнение идёт по разным веткам. Тогда получается что хоть явного параметра и нет, а на самом деле он есть.
Касательно метода PriceDisc.findPrice - ну это, как правильно замечено, один из важных методов системы, который считает цену. Для него 256 тестовых методов это в общем то может быть и нормально. Самое сложное, может быть, в данном случае это с помощью Reverse Engineering описать эти 256 сценариев.

[mazzy]

Цитата:

Сообщение от VORP

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

да, в принципе согласен.
но. задать надо вручную? 256 комбинаций?
тот, кто проводит ревью теста тоже должен проверить вручную?

когда добавится еще один параметр (и он будет дефолтным),
то бедняга добавляющий должен будет добавить еще 256 строк?
а ревьюирующий должен будет проверить вручную?

как уже говорилось, при таком подходе вероятность ошибки в тесте выше, чем вероятность ошибки в самом коде.

Цитата:

Сообщение от VORP

На самом деле тут (я имею ввиду Аксапту вообще) проблема другая, а именно что одним из параметров является состояние системы. Положим, для простоты что считывается значение из LedgerParameters, а дальше исполнение идёт по разным веткам. Тогда получается что хоть явного параметра и нет, а на самом деле он есть.

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

Цитата:

Сообщение от VORP

Касательно метода PriceDisc.findPrice - ну это, как правильно замечено, один из важных методов системы, который считает цену. Для него 256 тестовых методов это в общем то может быть и нормально. Самое сложное, может быть, в данном случае это с помощью Reverse Engineering описать эти 256 сценариев.

в принципе да.
но я понимаю людей, которые отвечают на такой довод "здравый смысл" )))))

[VORP]

но. задать надо вручную? 256 комбинаций? - Насчёт вручную не понял - но автоматизировать это мне кажется не получится если речь об этом. В моём понимании надо ревьюить не столько код теста, сколько описание сценариев, которое надо сделать до написание теста, иначе в таком случае недолго и запутаться.
Надо для каждого из параметров сформировать список "имеющих смысл" значений, например клиент который есть в PriceDiscTable, и которого нет или количество(Qty) больше порога или меньше, и на каждый написать тест.
Когда добавится новый параметр, надо опять же протестировать этот параметр с имеющими смысл значениями а также изменить интеграционный тест, как я понимаю. Ну то есть если бы добавили параметр количество(Qty которое уже есть) новых тестов было бы два + измененный интерграционный.

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

Я говорю о том что если окружение в разном состоянии то метод может работать по разному и это тоже может быть надо тестировать, то есть, например, проставлять разные значения в LedgerParameters.