Модульное тестирование математического кода

Question

Я пишу небольшую утилиту для вычисления сложной математической формулы (используя библиотеку commons-math для интеграции и поиска корней).Я пытался написать его так же, как и обычное бизнес-приложение, однако обнаружил, что получаю быстро растущее число классов.Чтобы получить первый шаг вычислений (1 строковая формула с 2 интегралами), я уже написал 3 класса для каждого крошечного бита вычисления, чтобы я мог использовать внедрение зависимостей и правильно смоделировать все вызовы commons-math.Это своего рода выход из-под контроля, хотя в итоге у меня будет 20 классов для задачи, которую можно решить на двух экранах в одном классе (без юнит-тестирования).Какой будет ваш предпочтительный подход?Я очень склонен полагаться только на приемочные испытания и тесты более высокого уровня.

Answer 1

Не позволяйте тестированию создавать совершенно непригодный и непонятный код.И не переоценивайте функциональное существо с объектно-ориентированным подходом.

Вы тестируете функцию, то есть существо без состояния, которое дает одинаковый результат для тех же аргументов.И я думаю, что именно так вы должны проверить это: дать ему аргументы из всех возможных классов эквивалентности и заявить о результате.

Answer 2

По моему опыту, вы должны использовать юнит-тестирование как проверку работоспособности и возможную проверку регрессии.Конечно, модульное тестирование должно быть как можно более тщательным, но иногда бывает очень утомительно, когда он полностью тестирует всю функциональность кода.

Модульные тесты не являются формальным доказательством.Они не могут и не будут предупреждать о будущих ошибках и проблемах с вашим кодом.Протестируйте общие случаи использования кода.Если вам нужна большая степень надежности, вам нужно будет создать большое хранилище регрессионных тестов.К счастью, для общих проблем есть несколько онлайн-баз данных для такого рода вещей. TPLP , например, это база данных проблем (и решений) для Доказателей Теорем.

Один метод, который иногда работает для меня ... обычно в математическом коде, есть "легкий, но медленный""методы" и "быстрые, но сложные в программировании" методы.При написании кода вы хотите использовать быстрый, но трудный для написания (так что вы ожидаете ошибок).Итак ... сделайте быстрый путь к тестируемой системе (SUT).Когда вы делаете модульный тест, создайте 1000 случайных задач и решайте их «простым, но медленным» методом.Затем запустите SUT и убедитесь, что ответы аналогичны.

Предполагая, конечно ..., что создание случайных проблем - это простая проблема, которую нужно решить.Иногда это так, иногда нет.Трудно сказать, не сказав нам о самом математическом коде.Теперь ... Это получает ВСЕ случаи?Нет. Но это получит "общие" случаи.И если на практике всплывает угловой случай, оберните его в модульном тесте и исправьте в следующей версии вашего кода.