Стратегии модульного тестирования и разработки на основе тестирования

Я большой сторонник разработки, основанной на тестировании, в научных вычислениях. Его полезность на практике просто ошеломляет и действительно облегчает классические проблемы, известные разработчикам кода. Однако при тестировании научных кодов, которые не встречаются в общем программировании, есть определенные трудности, поэтому тексты TDD не очень полезны в качестве учебных пособий. Например:

Как правило, вы не знаете точного ответа на данную сложную проблему априори, так как вы можете написать тест?
Степень параллелизма меняется; Недавно я столкнулся с ошибкой, из-за которой использование задач MPI как кратного 3 не удавалось, но кратное 2 сработало. Кроме того, из-за самой природы MPI обычные инфраструктуры тестирования не кажутся очень удобными для MPI - вам нужно повторно выполнить тестовый двоичный файл, чтобы изменить количество задач.
Научные коды часто имеют много тесно связанных, взаимозависимых и взаимозаменяемых частей. Мы все видели унаследованный код и знаем, как заманчиво отказаться от хорошего дизайна и использовать глобальные переменные.
Часто численный метод может быть «экспериментом», или кодер не до конца понимает, как он работает, и пытается его понять, поэтому предвидеть результаты невозможно.

Некоторые примеры тестов, которые я пишу для научного кода:

Для временных интеграторов используйте простой ODE с точным решением и проверьте, что ваш интегратор решает его с точностью до заданной точности, а порядок точности правильный, тестируя с переменным размером шага.
Тесты на нулевую стабильность: убедитесь, что метод с 0 граничными / начальными условиями остается на 0.
Интерполяционные тесты: при наличии линейной функции убедитесь, что интерполяция правильная.
Устаревшая проверка: выделите фрагмент кода в унаследованном приложении, которое, как известно, является правильным, и извлеките некоторые дискретные значения для использования для тестирования.

До сих пор часто всплывает, что я не могу понять, как правильно протестировать данный фрагмент кода, кроме проб и ошибок вручную. Можете ли вы привести несколько примеров тестов, которые вы пишете для числового кода, и / или общих стратегий тестирования научного программного обеспечения?

testing

— Аврелий
источник

Не могли бы вы уточнить, что вы подразумеваете под интерполяционными тестами?

— Дмитрий Кабанов

Ответы:

Метод изготовленных решений .

С помощью уточняющих исследований убедитесь, что метод достигает теоретического порядка точности.

Сохранение ответа. Битовое и нормальное воспроизведение решений.

— Билл Барт
источник

Я хотел упомянуть MMS в оригинальном сообщении; это хорошо для проверки кода, но с точки зрения модульного тестирования это совершенно бесполезно. Если эти тесты не пройдены, это не дает понятия, где и почему.

— Аврелий

2 \times 2 \times 2

$2\times 2\times 2$

Множество литературы, которую я видел по MMS, в основном являются глобальными решениями, например, для проблем с CFD, изготовленное решение может быть анализом аэродинамического профиля. Когда этот тест не пройден, в лучшем случае вы сузили преступника до 5000 строк кода, так что это довольно бесполезно для TDD - у вас нет ни малейшего понятия, где происходит настоящий сбой. Я согласен, что проблема 2x2x2 чрезвычайно ценна, и я лично часто их использую. Но довольно часто я сталкиваюсь с проблемами, которые появляются только в больших системах; Я недавно обнаружил ошибку компилятора ifort, которая проявлялась только в больших проблемах.

— Аврелий

@ Аврелий: Здесь нет аргументов. Вы должны иметь ряд тестов и часто их запускать.

— Билл Барт

@Aurelius По номинальной стоимости MMS - это не модульный тест, а функциональный или приемочный тест (т. Е. Всей системы). Однако коды часто имеют отдельные этапы (или могут быть разделены на них). например, адвекция, давление, вязкость. Затем можно протестировать только один из этих этапов («блок»). Точно так же код может быть протестирован без BC, а затем с одним. Один из друзей сделал свою докторскую диссертацию по модульному тестированию, и он считал, что наибольшее преимущество заключалось в том, что он заставил вас разбить вашу программу на модули, чтобы она могла быть проверена модулем ... возможно, это более применимо, чем кажется на первый взгляд (и в других отношениях я не знаю).

— hyperpallium

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

Обращаясь к третьему пункту, нет, нет причин вводить сильную связь между частями. Как раз наоборот: если ваши функции или классы имеют четко определенные интерфейсы, будет гораздо проще заменить, например, линейный решатель на другой или схему пошагового перехода по времени. Просто не поддавайтесь этому, и тогда вы сможете протестировать эти компоненты отдельно. Мы делали это с deal.II на протяжении десятилетий.

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

— Гвидо Каншат
источник

Чтобы добавить ответ Гвидо, опыт, с которым он говорит, закодирован в ~ 3000 тестов, которые мы проводим на deal.II после каждого изменения: dealii.org/developer/development/… . На вопрос, что делать, если вы не знаете точного ответа: все равно напишите тест и позвольте ему сравнить ответ сегодня с ответом вчера (или всякий раз, когда вы написали тест). Наличие способа обнаружить изменения в выводе кода является полезным, даже если вы не знаете, сделали ли они неправильный ответ или исправили ранее неверный ответ.

— Вольфганг Бангерт

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

http://cyber.ua.edu/files/2014/12/u0015_0000001_0001551.pdf

— Магне
источник

Я просмотрел некоторые вступления и выводы, и, предполагая, что уровень качества на уровне стандартной докторской диссертации, это объясняет процесс (на высоком уровне) и дает реальные измерения его эффективности. Я думаю, что это настоящая находка.

— Годрик Провидец

Ссылка мертва. Возможно, вы имели в виду: Nanthaamornphong, A. «Эффективность методов разработки и рефакторинга на основе тестов в вычислительной науке и разработке инженерных программ». Доктор философских наук, Uni. Алабама (2014).

— AlQuemist