На мой взгляд, это примерно то же самое, что говорить: «зачем мне тестировать слой бизнес-логики в моей e-Commerce системе?! Там же есть формулы, расчеты, сложные логические условия, запросы к базе [если вы пользуетесь паттерном Repository и ORM, то высокоуровневые запросы, скорее всего, будут в слое бизнес-логики], зависимости между классами и тп». Разница с научными приложениями в том, что в случае e-Commerce вы-таки можете добавить эффективные юнит-тесты там, где они нужны, а в научных--не всегда. Что я и надеялся продемонстрировать.
Кстати, скажу по секрету, все системы для моделирования гидродинамики по умолчанию многопоточные, потому что иначе от них никакого толку:) Даже запись результатов моделирования в файлы делают многопоточной обычно--из-за объемов данных. Да и программы для просмотра этих результатов--тоже, как ни странно, многопоточные. www.paraview.org/ (Parallel Viewer)
Признаюсь, я не большой эксперт в области тестирования ПО, но, кажется, это описания тестов в разных иерархиях: unit->integration->system testing и functional/non-functional. en.wikipedia.org/wiki/Software_testing
У опытных данных есть проблемы: 1. они с погрешностями (огромными для верефикации численных методов) 2. никому не удастся померять поле скоростей в сосуде с жидкостью. Максимум--какие-то усредненные значения, либо безразмерные величины (типа числа Нуссельта) 3. измерения искажают поле скоростей и температур.
Поэтому используют либо сравнение с известными аналитическими решениями, либо с другими численными. Притом бенчмарки выбирают так, чтоб проверялись какие-то характерные эффекты. www.cfd-online.com/Wiki/Lid-driven_cavity_problem
К том конкретному алгоритму, по-моему, применимо очень мало способов. Дело вот в чем. Алгоритм выглядит примерно так: посчитать матрицу K (формула на строчку), посчитать вектор a (формула на строчку), и тп — 10 пунктов. Максимум, что мне удалось сделать, это разбить класс на методы типа ComputeMatrixK, ComputeVectorA и тп. Выносить их в отдельные провайдеры глупо--это будут классы типа MatrixKProvider, VectorAComputer и тп. Они только хуже сделают, а тестировать их все равно невозможно--у них нет ясного смысла.
Ответ немного непрямой: программа в моем случае была рассчитана на моделирование потока в пористой трубке популярных химических реакторов (http://en.wikipedia.org/wiki/Fluidized_bed_reactor). В этом институте пробовали провести измерения температур физически, но оказалось, что датчики, во-первых, плотно не расставить, во-вторых, можно расставить только снаружи реактора, в-третьих, они искажают поле скоростей и температур своим присутствием.
Если использовать Symbolic Toolbox в MATLAB в качестве системы компьютерной алгебры, то обычно хватает встроенного мануала. Раньше это и была обертка над Maple, правда, сейчас они переключились на другую реализацию--MuPad.
Самое главное--они не модульные. Обычно вам надо запускать всю программу целиком. Во-вторых, они медленные (см. раздел Малая скорость возрастания ошибок). То есть, чтобы сравнения с аналитическими решениями были хоть сколько репрезентативны, надо довольно долго проводить моделирование. Наконец, эти решения сами по себе далеко не тривиальны, то есть в качестве простого автоматического теста не подходят. Такие решения--это обычно майлстоуны в процессе разработки, и проверяются вручную. Примеры: www.openfoam.com/docs/user/cavity.php, en.wikipedia.org/wiki/Taylor%E2%80%93Couette_flow, physics.ucsd.edu/was-daedalus/convection/rb.html
Поэтому используют либо сравнение с известными аналитическими решениями, либо с другими численными. Притом бенчмарки выбирают так, чтоб проверялись какие-то характерные эффекты. www.cfd-online.com/Wiki/Lid-driven_cavity_problem