たちです。
Yoda Kiwamuさんの<200104170200.LAA01262@....jp>から
>>できればデバイスドライバもテストしたいですし。
>ここなんですが、
>デバイスドライバのUnit Testってどうお考えですか??
ハードウェアの機能をソフトウェアで拡張した部分についてはテストできると
思います。ドライバといってもこのクラスでは特別なしかけがあるわけもない
ので、問題は割り込みと排他制御くらいでは。問題ってまあフレームワーク側
の話ですけど。
ハードウェアの使い方についても、こういう操作をしたときは、ステータスや
バッファがこういう状態になるはずという、ハードウェアの仕様確認みたいな
テストは単独でできると思います。内部に状態を山ほど持つような、極端にイ
ンテリジェントなデバイスだと難しそうですが。
>EEPROMやFLASHみたいに、
>チップ側から完全に制御できるデバイスならともかく、
>キー入力とかLCD出力とか、
>人間が操作したり目で確認してやらにゃあならんデバイスが
>あまりに多い。
プロセッサから見て書き込み一方なデバイスはどうしようもないのでは。重要
な開発ならデバッグ用の特別なハードウェアを作るのかもしれませんけど、わ
たしはそういうケースを見たことないです。
読み込み一方なら、入力してくる側のプログラム(含む人間)を何とかすれば、
何とかなりそうです。もしも入力してくる側の動作に問題がありそうだったら
(お互いに)再度テストを流すと。
>僕の場合は、実環境上では、単純に assertを
(中略)
>それ以外のことはやってません(笑
ハードウェアの動作確認ということになると、いつどこで何が起きるのかわか
らないので、実際に動作させるソースコード中にテストを埋め込み、安定する
までテストを続けることになりそうです。
テストといっても変にハードウェアをいじると副作用がありますし、ハードウ
ェアデバッグが一応終わったことになっても実は同じ条件チェック&処理が必
要だったりします。リリース時にはassertを削除するので、結局、assertに条
件を書かず、
if(condition){
assert(FALSE);
....
} else {
assert(TRUE);
}
とかしたりするのでは。
こういうのもunit testと言うのかどうかわかりませんが、unit test用のしか
けは使えそうです。テストを100万回通過して10回変な分岐をしてたのが、0回
になったから問題はほぼ解消されたのではないかとか。
#……こんなこと言ってていいのだろうか。
で、先のライブラリはこんな用途にも使うつもりで書いてみました。
--
Yoshihiro TACHI mailto:tati@....jp