Как протестировать научное программное обеспечение?
Я убежден, что тестирование программного обеспечения действительно очень важно, особенно в науке. Однако за последние 6 лет я никогда не сталкивался ни с одним научным программным проектом, который проходил регулярные испытания (и большинство из них даже не контролировались версиями).
Теперь я Мне интересно, как вы справляетесь с тестами программного обеспечения для научных кодов (числовые вычисления).
С моей точки зрения, стандартные модульные тесты часто упускают суть, поскольку нет точного результата, поэтому использование assert (a == b) может оказаться немного сложным из-за «нормальных» числовых ошибки.
Так что я с нетерпением жду ваших мыслей по этому поводу.
3 ответа
Я тоже учусь в академических кругах, и я написал программы квантово-механического моделирования, которые будут выполняться на нашем кластере. Я сделал то же наблюдение относительно тестирования или даже контроля версий. Мне было еще хуже: в моем случае я использую библиотеку C ++ для своих симуляций, а код, который я получил от других, был чистым спагетти-кодом, без наследования, даже без функций.
Я переписал его, а также реализовал несколько модульных тестов. Вы правы, что вам нужно иметь дело с числовой точностью, которая может быть разной в зависимости от архитектуры, на которой вы работаете. Тем не менее, модульное тестирование возможно, если вы учитываете эти числовые ошибки округления. Ваш результат не должен зависеть от округления числовых значений, иначе у вас возникнут другие проблемы с надежностью вашего алгоритма.
Итак, в заключение, я использую модульное тестирование для своих научных программ, и это действительно делает человека более уверенным в результатах, особенно в том, что касается публикации данных в конце.
Пожалуйста, взгляните на ответы на вопрос SO Как правильно использовать TDD для реализации численного метода?
Я также использую cpptest для его TEST_ASSERT_DELTA. Я пишу высокопроизводительные численные программы в области вычислительной электромагнетики и с удовольствием использую его в своих программах на C++.
Обычно я тестирую научный код так же, как и любой другой код, только с некоторыми изменениями, а именно:
Я всегда проверяю свои численные коды на случаи, не имеющие физического смысла, и убеждаюсь, что вычисления действительно останавливаются, прежде чем выдать результат. Я научился этому трудным путем: У меня была функция, которая вычисляла некоторые частотные характеристики, затем передавала матрицу, построенную с их помощью, другой функции в качестве аргументов, которая в итоге выдавала ответ в виде одного вектора. Матрица могла быть любого размера в зависимости от того, на сколько терминалов подавался сигнал, но моя функция не проверяла, соответствует ли размер матрицы количеству терминалов (2 терминала должны были означать матрицу 2 x 2 x n); однако сам код был обернут так, чтобы не зависеть от этого, ему было все равно, какого размера были матрицы, поскольку он просто должен был выполнять над ними некоторые базовые матричные операции. В конце концов, результаты оказались вполне правдоподобными, в пределах ожидаемого диапазона и, фактически, частично правильными - только половина вектора решения была искажена. Мне потребовалось время, чтобы понять. Если ваши данные выглядят корректно, собраны в правильную структуру данных и числовые значения хороши (например, нет NaNN или отрицательного числа частиц), но это не имеет физического смысла, функция должна работать изящно.
Я всегда тестирую процедуры ввода-вывода, даже если они просто считывают кучу чисел, разделенных запятыми, из тестового файла. Когда вы пишете код, который занимается извращенной математикой, всегда заманчиво перейти к отладке той части кода, которая настолько перегружена математикой, что вам нужен кофеин, чтобы понять символы. Спустя несколько дней вы понимаете, что добавляете в список пунктов значение ASCII
\n.При проверке математического соотношения я всегда проверяю его "по правилам", и я также научился этому на примере. Я видел код, который должен был сравнить два вектора, но проверял только равенство элементов и не проверял равенство длины.