ユニットテストとテスト駆動開発の戦略

私は、科学コンピューティングのテスト駆動開発の大擁護者です。実際のところ、このユーティリティは驚異的であり、コード開発者が知っている古典的な問題を本当に軽減します。ただし、一般的なプログラミングでは発生しない科学的コードのテストには固有の困難があるため、TDDテキストはチュートリアルとしてそれほど有用ではありません。例えば：

• 一般に、与えられた複雑な問題に対する正確な答えはアプリオリにわからないので、どのようにテストを書くことができますか？

• 並列度が変化します。最近、MPIタスクを3の倍数で使用すると失敗するが、2の倍数で動作するというバグに遭遇しました。さらに、一般的なテストフレームワークは、MPIの性質上、MPIにあまり適していません。タスクの数を変更するには、テストバイナリを再実行する必要があります。

• 科学コードには、多くの場合、密結合され、相互に依存し、交換可能なパーツが多数あります。私たちは皆、レガシーコードを見てきましたが、良いデザインを放棄してグローバル変数を使用することがどれほど魅力的かを知っています。

• 多くの場合、数値的手法は「実験」であるか、コーダーがその方法を完全に理解しておらず、理解しようとしているため、結果を予測することは不可能です。

科学コード用に書いたテストの例：

• 時間積分器については、正確な解をもつ簡単なODEを使用し、積分器が所定の精度内でそれを解くかどうかをテストします。さまざまなステップサイズでテストすることにより、精度の順序が正しいです。

• ゼロ安定性テスト：境界/初期条件が0のメソッドが0のままであることを確認します。

• 補間テスト：線形関数が与えられた場合、補間が正しいことを確認します。

• レガシー検証：正しいことがわかっているレガシーアプリケーションのコードのチャンクを分離し、テストに使用するためにいくつかの離散値を引き出します。

手動での試行錯誤は別として、特定のコードチャンクを適切にテストする方法がわからないことがよくあります。数値コード用に記述するテストの例や、科学ソフトウェアをテストするための一般的な戦略を提供できますか？

製造ソリューションの方法。

精密化の研究を通じて、メソッドが精度の理論的な順序を達成していることを確認します。

回答の保存。ソリューションのビット単位および標準単位での再現。

ビルはあなたの懸念に対処するいくつかの方法をすでにリストしています。

3番目のポイントに対処します。いいえ、部品間に強い結合を導入する理由はありません。反対に、関数またはクラスに明確に定義されたインターフェイスがある場合、たとえば線形ソルバーを別のものに交換したり、タイムステッピングスキームを交換したりするのがはるかに簡単になります。抵抗するだけで、これらのコンポーネントを個別にテストできます。私たちはこれをdeal.IIで何十年も行いました。

4番目のポイント：メソッドが実験の場合、メソッドを使用した実験はテストを構成します。分析がない限り、これらのテスト結果を可能な限り利用する必要があります。しかし、通常は、たとえばメソッドの順序に期待があるか、特定のクラスの解、たとえばある程度までの多項式に対して正確であることがわかります。これらを検証することは実験の一部である必要があり、分析が向上するにつれてテストを追加できます。

私は最近、計算科学のTDDに関するこの論文を見つけました。私はまだそれを読んでいませんので、それが良いかどうかはわかりませんが、うまくいけば助けになるかもしれません。

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