私は現在、いくつかのフーリエ変換を行うためにいくつかのクラスを作成しようとしています。最初にいくつかの単体テストを作成してから、基本的な機能を構築することでそれを実行しようとしています。
これに伴う問題は、アルゴリズムが機能するかどうかを確認するためのテストを1つ作成でき、期待される結果がわかっていることです。次に、大きなアルゴリズムの構築を開始します。それが機能する場合、単体テストに合格します。
ここでの私の問題は、実際にはTDDではないということです。通常、クラスの非常に基本的な機能をテストするテストを作成するためです。現在、私のクラスは基本的に1つの大きなアルゴリズムを実行しますが、アルゴリズムの小さな部分は公開されていないため、テストできません（プライベートメソッドはテストしたくないといつも言われています）。
これにどのように対処しますか？
私は2つの可能な方法を見ます：
最近、「ユニットってなに？」と戦っています。これは確かに難しい質問です。
FFTのサブユニットが特にエラーを起こしやすいと信じる理由がある場合は、境界条件を整えて、プライベートメソッドが免除されるというルールを破ります。
同じことを別の言い方をすると、サブユニットは実際にはFFTによってサービスが使用されるユニットであり、ルールに違反しているわけではありません。
クラスにテスト可能なメソッドが1つしかない場合（パブリックメソッドのみをテストするという基準に従って）、そのメソッドのみをテストする以外に選択肢はほとんどありません。ただし、これはTDDではないという意味ではありません。さまざまな入力値を確実にテストできます。ここでの作業のほとんどは、興味深い値を見つけることです-変換が失敗する可能性のあるエッジケースは何ですか？無効な入力はありますか？また、どのように処理されますか？
正常なルーチンを呼び出す、キーフーリエ関連の識別を使用する、またはFFTを使用して乗算を行うなど、多くの値のアルゴリズム検証を行う方法はありますか？
アルゴリズムの個々のコンポーネントをテストできない場合は、コードが非常に緊密に結合されているか、コードが非常に手続き型であると思います。
コードをユニットとして定義し、これらのユニットを保護されたメソッドにする必要がある場合があります。メソッドが保護されている限り、APIの一部ではないという明確なメッセージを送信します。