低レベルのコンポーネントでTDDを実行することは良い考えですか？
低レベルのドライバーまたはOSコンポーネント/カーネルの作成を検討しています。
osdev.org の人々は、重要な部分はこの方法では有意義にテスト可能ではないと考えているようですが、私は人々が異なる考え方をしたいくつかの議論を読みました。私は見回しましたが、低レベルコンポーネントのTDDの実際の例を見つけることができませんでした。
これは実際に人々が行うことですか、それとも実際にはそれを行う良い方法がないために理論的に人々が話していることですか？
私は個人的に、TDDの多くの利点を（実際にTDDを遵守することなく）得ることができると信じがちです。
- callerとcalleeの両方のコードをほぼ同時に（間違いなく24時間以内で）書いている。
- そして、それを使用して、インターフェース（オブジェクト、メソッド呼び出し、パラメーター）の設計に影響を与えます。
- 複雑なアルゴリズム/コードを必要とするコンポーネントの場合、効率が低くても（または愚かであるか、またはより狭い状況でしか機能しない場合でも）、最初に単純で正しいアルゴリズムで実装することを強く検討してください。
- 非常に単純なテスト方法は、両方のアルゴリズムを実行し、それらの結果を比較することです。
- コードの一部でバグが（何らかの手段で）発見されたら、コードのその部分をより積極的にテストする価値があります。これは、TDDが要求するよりも高度なテストを行うことを意味します。 （バグがクラスタで発生するという推論に基づいて）
TDDでは、実装する機能を計画するか、実装する機能を計画する要件をかなり明確に理解する必要があるようです。コードを実装することによって。状況によっては、問題の理解が不十分な場合があります。これはSpikeソリューションを必要とするでしょう。このSpikeソリューションの範囲内で、問題が管理可能なレベルに絞り込まれたため、TDDを適用できます。いくつかのスパイクが完了し、それぞれが元の問題のいくつかの側面をカバーしたら、完全なソリューションに取り掛かることができます。その時点でTDDを適用することは、理解が深まるため、実現可能かもしれません。
編集：
ページを注意深く読んだ後、
「テストベッド」テストドライバでほとんどのカーネル機能をテストすることは可能ですが、割り込み処理、プロセスディスパッチ、またはメモリ管理などの本当に「ジューシー」なものは、おそらくユニットテスト可能ではありません。 ---から http://wiki.osdev.org/Unit_Testing
彼らは、ほとんどのパーツがテスト可能であり、一部のパーツは異なる種類のテストを必要とすることを明確に述べています：ストレステスト。
ハードウェアを操作または制御している場合、ハードウェアなしでテストすることは困難です。ハードウェアのエミュレーションを試すこともできますが、多くの場合、最初にドライバーを作成するよりも難しいので、バグがドライバーにあるのかエミュレーターにあるのかが分からなくなります。
私はしません。私のマスターの埋め込みコードでは、コードを記述して、コードの機能（および機能しない）の推論に時間を費やしています。とにかく私の場合にそれができるかどうかはわかりませんが、テストコードを注入せずにメモリの物理的な限界に驚くほど近づいています。
十分な大きさのシステム（つまり、KBではなくMBのメモリを搭載しているシステム）では、十分な時間と労力があれば、一部のコンポーネントに対して実行できると思います。ピンをモックアップしてピン読み取りコードをテストすることは...そう...あまり意味がありません。ロジックを十分に分離した場合は、ロジックを別の場所でテストできます。
FWIW、私は一般的なケースでTDDを購入しません-十分なリソースと十分な決定論的動作を備えた十分な大きさのシステムスタックでは正常に機能します。