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