TDDを使用した複雑なアルゴリズムの構築

私は毎日のプログラミングの練習でTDDを採用しようとしています。私は仕事でそれを非常に効果的に使用していますが、いくつかの複雑なアルゴリズムを使用している私の個人的なプロジェクトで問題を抱えています。

この質問をさせる特定のアルゴリズムは、拡張カルマンフィルターです。私が書いたコードに自信が持てないほど複雑ですが、分割するのが難しいほど単純です。

入力と予想される出力を使用してアルゴリズムのテストを作成することもできますが、中間のステップには自信がないため、途中でスラッシングとショットガンコーディングをたくさん行います。

合理的で複雑なアルゴリズムを使用してTDDを使用したことがある場合、アプローチは何ですか。

TDDは設計の代わりにはなりません。

これはTDDに関する一般的な誤解です。レッドグリーンリファクタリングから一貫した設計を何らかの方法で「成長」させることができるということです。できません。あなたのテストはあなたの設計スキルによって導かれる必要があります。

テスト中のメソッドの入力と出力の間で何をすべきかを理解しようとしている場合、それはおそらく、単一のメソッドであまりにも多くのことを実行しようとしていることを意味します。それらの中間ステップが何をすべきかを考えてください。これらの中間ステップのテストを記述し、それらのテストに合格するメソッドを記述します。

TDDは複雑なアルゴリズムに使用できます。明確で意味のあるテストをたくさん書いて、それらを使ってプログラムを設計してください。アルゴリズムでランダム化が使用されている場合は、何らかの依存性注入を使用し、ランダム化を個別にテストします。TDDは、高品質のアルゴリズムを記述するために使用する多くの方法の1つです。コードレビュー、ロギングなどです。

入力と予想される出力を使用して、アルゴリズムのテストを作成できます。

「a」テストを記述しないでください。TDDは、一度に1つのテストを記述しません。アルゴリズムのさまざまな境界と標準入力をチェックする複数のテストを最初に記述します。

私はTDDを使い始めたばかりですが（読んでいるので、おそらく正しく行っていません）、どの入力がどの出力に一致するかを簡単に推論できる場合は、簡単に記述できるアルゴリズムの方が適しているようです。

「まだどうなるかわからない」という作業を続けていると、TDDはあまり役に立ちませんでした。代わりに、アサーションを非常に自由に使用して、これまでの動作方法を確認します。このようにして、有効なターゲットであるかどうかわからないターゲットにコードを記述しようとしてスタックすることはありませんが、ある程度の保護を得て、コードの小さな部分に痛みの領域をローカライズします。

アルゴリズムが正しいかどうかを確認した後（少なくともいくつかの入力->スポットチェックの出力については確かです）、戻ってテストを記述します。その後、戻ってリファクタリングするか、速度やリソースの使用量を最適化する方がはるかに安全です。

私はこの種のものがRDDに適していると思います：読み取り駆動型開発。

これは、カルマンフィルターのような複雑なもののアルゴリズムを本で読み、それをターゲット環境での実装に変換する場所です。

不利な点は、その方法で処理を行うと、設計プロセスの一環として無料でテストケースを取得できないことです。一方、そのように知られているものにはほぼ確実に既存の実装があります（例：Commons Math）。そして、それを新しい実装のテストオラクルとして使用するのは簡単です。心配する必要があるのは、テストケースのセットがコード内のすべてのパスをカバーすることだけです。