数値ソフトウェア開発のためのテストフレームワークはありますか

私の計算科学プログラミングの多くに、標準のテストフレームワークではカバーされないテスト要件があることがわかりました。

1. 計算時間テスト

   • アルゴリズムが遅くならないようにするため。私は次のようなことをすることができます assureSmallerEqual(RuntimeWrapper(algorithm),53)が、アルゴリズムに取り組んでいるときに53秒のしきい値を継続的に減らしたい、つまりassureSmallerEqual(RuntimeWrapper(algorithm),'previousbest+noisetolerance')

2. 性能試験

   • 以前に分析解の良い近似を見つけたアルゴリズムが、少なくとも同じかそれ以上の解を見つけることを確認するため。繰り返しになりますが、これは標準の統合テストでエミュレートできますが、アルゴリズムが次第に良くなるにつれて、許容範囲を継続的に縮小したいと思います。交換assureAlmostEqual(foo(),1,places=3)することを考えるassureAlmostEqual(foo(),1,places='previousbest')

3. 物理的要件のテスト

   • アルゴリズムが突然より多くのメモリ/ハードディスク領域を必要としないことを確認するため。1に非常に似ています。

4. 抽象要件テスト

   • 二次近似でうまくいったアルゴリズムが突然3次近似を必要としないこと、またはタイムステップ0.1でうまく行ったアルゴリズムが安定性のために突然0.01を必要としないことを確認するため。繰り返しになりますが、これらは標準の統合テストでエミュレートできますが、目標は、特定の目標を達成した最小要件パラメーターを覚えておくことです。そのため、これには多くの手動更新が必要になります。たとえば、foo(10)以前に例外がスローされなかった場合は、フレームワークがfoo(10)引き続き機能することを確認し、現在機能するかどうかを試しfoo(9)ます（この場合、今後のすべてのテストで機能することを確認しfoo(9)ます）。

たとえば、ランタイムの増加は他の改善の見返りとして受け入れられる可能性があるため、私が求めているのはユニット/統合テストの意味でのテストについて記述していないと主張することができます。
ただし、実際には、上記のテスト機能があれば、導入したバグのために要件とパフォーマンスが95％失敗したため、デバッグ時間を大幅に節約できたと思います。実際、外部の数値ソフトウェアライブラリを使用して（多くの時間を自分のコードのチェックに費やした後で）見つけた多くのバグは、上記のテストを厳密に適用すれば、簡単に回避できたという事実を知っています。

PS

同様の名前の質問/programming/34982863/framework-for-regression-testing-of-numerical-codeは、標準の回帰テストフレームワークでより簡単に達成できる機能を説明しているため、重複していません。

質問ユニットテストとテスト駆動開発のための戦略、それらを実装する（とその答えで提供され、それは/を要求戦略が、私は私の意見では、ここで説明するものとは異なっている）ことができますフレームワークとは対照的に、戦略を要求します。

1.このタイプのテストは、開発時にテストを実行した特定のマシンにテスト条件が関連付けられているため、定義が不十分であるように見えます。テストのポイントの1つは、私のラップトップでテストを実行すると、コードや設定した環境に問題がないかどうかがわかることです。53秒は開発マシンに固有であり、テストマシンに他のワークロードまたはユーザーからの負荷がかかっている場合、実行時間も増加します。私は、テストフレームワークがこれに対処することを期待していません。「53秒未満の入力で関数が実行される」は、あまり正確な仕様ではありません。

2.私は、この曖昧と同じ理由のためのソフトウェアテストの観点から望ましくないと思う1を、あなたは、ソフトウェアのテストのためのパスまたはフェイル正当性を失います。

3.これは非常に一般的です。1つの解決策を説明しましょう。これはテストフレームワークの仕事ではありませんが、Unix SEの質問「単一のLinuxプロセスのメモリ使用量を制限する」で説明されているように、別のツールを使用できます。最初に試す標準ツールの1つは、のulimitコマンドですbash。これにより、プロセスを実行し、メモリを割り当てすぎた場合などに、プロセスがクラッシュすることを確認できます。したがってruntests、メモリ制限を設定してスクリプトを実行すると、スクリプトがクラッシュし、テストフレームワークは通常のテストエラーとして処理できるはずです。

4.ほとんどのテストフレームワークは、ユニットテストをこのようにまったく考えていません。テストスイートが実行され（たとえば、コードをマスターにコミットする前、またはデプロイする前）、結果は、機能するかどうかを示すyesまたはnoです。テストフレームワークは、たとえば機能の進捗状況を追跡することを自分たちの仕事の一部とは見なさず、それが一般的なテストの目的ではありません。ここでは、2つのテストを記述しますexpect_succeeds(foo(10)); expect_fails(foo(9))。毎回、両方のテストが実行され、成功と予想される失敗がパスします。実装foo(9)して成功すると、expects-failureテストが失敗するので、書き換えますexpect_succeeds(foo(9))、そしてこれはすべてのフレームワークの絶対標準機能です。ただし、そうでない場合はソフトウェアテストの基本的な考え方に反するだけなので、期待する動作を明示する必要があります。

$A$$A$$A$$B$performs_better(foo_A(), foo_B())$B$$A$$B$、および（b）コードを以前のコードと比較する意味がなくなったため、すべてのコードとテストが不変で明確になります。これは、システムの書き換えを処理する方法と精神的に似ています。