低レベルのコンポーネントでTDDを実行することは良い考えですか？

低レベルのドライバーまたはOSコンポーネント/カーネルの作成を検討しています。

osdev.orgの人々は、重要なビットが有意義にこの方法をテスト可能されていないことを考えているようだが、私は人々が異なったと思ったいくつかの議論を読んだことがあります。私は見回しましたが、低レベルコンポーネントのTDDの実際の例を見つけることができませんでした。

これは実際に人々が行うことですか、それとも実際にはそれを行う良い方法がないために理論的に人々が話していることですか？

ハードウェアを操作または制御している場合、ハードウェアなしでテストすることは困難です。ハードウェアのエミュレーションを試すこともできますが、多くの場合、最初にドライバーを作成するよりも難しいため、バグがドライバーにあるのかエミュレーターにあるのかが分からなくなります。

私は個人的に、TDDの多くの利点を（実際にTDDを遵守することなく）得ることができると信じがちです。

• 呼び出し元と呼び出し先の両方のコードをほぼ同時に（間違いなく24時間以内に）記述します。
  • そしてそれを使用して、インターフェース（オブジェクト、メソッド呼び出し、パラメーター）の設計に影響を与えます。
• 複雑なアルゴリズム/コードを必要とするコンポーネントの場合、効率が低くても（または愚かであるか、またはより狭い状況でしか機能しない場合でも）、最初はより単純だが正しいアルゴリズムで実装することを強く検討してください。
  • 非常に単純なテスト方法は、両方のアルゴリズムを実行し、それらの結果を比較することです。
• コードの一部でバグが（何らかの手段で）発見されたら、コードのその部分をより積極的にテストする価値があります。これは、TDDが要求するよりも高度なテストを行うことを意味します。（クラスターでバグが発生するという推論に基づく）

TDD では、実装する予定の機能、またはコードを実装することによって満たす予定の要件をかなり明確に理解する必要があるようです。状況によっては、問題の理解が不十分な場合があります。これはスパイクソリューションを必要とするでしょう。このスパイクソリューションの範囲内で、問題が管理可能なレベルに絞り込まれたため、TDDを適用できます。いくつかのスパイクが終了し、それぞれが元の問題のいくつかの側面をカバーしたら、完全なソリューションに取り掛かることができます。その時点でTDDを適用することは、理解が深まるため、実現可能かもしれません。

編集：

ページを注意深く読んだ後、

「テストベッド」テストドライバでほとんどのカーネル機能をテストすることは可能ですが、割り込み処理、プロセスディスパッチ、またはメモリ管理などの本当に「ジューシー」なものは、おそらく単体テスト可能ではありません。--- http://wiki.osdev.org/Unit_Testingから

彼らは、ほとんどの部品がテスト可能であり、一部の部品には異なる種類のテストが必要であることを明確に述べています：ストレステスト。

私はしません。私のマスターの埋め込みコードでは、コードを記述し、コードの機能（および機能しない）の推論に時間を費やしています。とにかく私の場合にそれができるかどうかはわかりませんが、テストコードを注入せずにメモリの物理的な限界に驚くほど近づいています。

十分な大きさのシステム（つまり、KBではなくMBのメモリを搭載しているシステム）では、十分な時間と労力があれば、一部のコンポーネントに対して実行できると思います。ピンをモックアップしてピン読み取りコードをテストすることは...そう...あまり意味がありません。ロジックを十分に分離した場合は、他の場所でロジックをテストできます。

FWIW、私は一般的なケースでTDDを購入しません-十分な決定論的動作を備えた十分なリソースを備えた十分な大きさのシステムスタックでは正常に機能します。