web-dev-qa-db-ja.com

単体テスト中にハードウェアの依存関係を処理する

テスト駆動開発アプローチを使用してIMUセンサーのドライバーを書いています。選択する通信プロトコルはSPIです。 CubeMXとSTM32F415プロセッサを使用して、SPI=インターフェイスはstm32f4xx_hal_spi.hファイルに実装され、多くの関数宣言が含まれています） 。これに注意してくださいSPIインターフェースはプロセッサー固有であり、IMUドライバーは異なるプラットフォームに実装することもできるため、柔軟性も重要です。

テスト駆動開発のニーズでは、SPIドライバーコード内で使用する関数をモックする必要があります。2つの可能なオプションを考え出しました。

1）オリジナルSPIヘッダーファイルstm32fxx_hal_spi.hがドライバーヘッダーに直接含まれています。センサードライバーで実際に使用される関数はごくわずかですが、その内容全体がモック化されます。

[〜＃〜]プロ[〜＃〜]

  • 簡単な実装

[〜＃〜] con [〜＃〜]

  • 実際のSPIドライバーファイルはセンサードライバープロジェクトにコピーする必要があります
  • ファットインターフェイスのモック


2）ドライバープロジェクト内にspi.hヘッダーを作成します。ドライバーによって使用されているが、元々はstm32fxx_hal_spi.hで宣言されている関数を再宣言します。モッキングspi.hは、実際に使用される関数に対してのみモックを提供します。

[〜＃〜]プロ[〜＃〜]

  • プロセッサー固有のSPIドライバーファイルをセンサードライバープロジェクトにコピーする必要はありません

  • 使われているものだけを模擬

[〜＃〜] con [〜＃〜]

  • テスト走行は簡単に思えますが、ハードウェアと統合する方法がわからないstm32fxx_hal_spi.hファイル

2番目のアプローチは、spiの実装を単一のヘッダーファイルに抽象化するという点で、より良い働きをするように思えます。しかし、前述のように、センサードライバーをプロジェクト全体に統合する際に、これを実際のspiドライバーファイルにリンクする方法がわかりません。

これらのいずれかは有効なアプローチと見なされますか？ドライバー開発中に、これに対して一般的に受け入れられているアプローチはありますか？

designunit-testingctddmocking
2
hbrezak

従来のオブジェクト指向アプローチを使用することをお勧めします。プレーンなCコードでも、これはかなり簡単です。

struct spiInterace {
   void* privateData;
   void (*eachFunctionInSPIInterface)();
};
typedef struct spiInterace  spiInterace ;

次に、実際のSPIインターフェースは「新しい関数」を提供します：

spiInterace* mkstm32f4xx_hal_spi()
{
   // malloc object, add any needed private data pointer (like
   // to memory mapped or open file descriptor) and fill in
   // function pointers to APIs now moved to static functions
}

...同様に、 'モック' SPIデバイスドライバ。

すべての呼び出しをspiIntrfaceオブジェクトを介して間接的に変更します。

   spiInterface* spiI = // call one mkFunction or the other for testing or real;
   // instead of earlier call to eachFunctionInSPIInterface(someSPIdesignator);
   spiI->eachFunctionInSPIInterface ();

そうすれば、テストは簡単です。どちらか一方のspiInterfaceを作成するだけです。

お役に立てば幸いです。

4
Lewis Pringle