テストファーストという開発手法があるが、この手法は前程として
・テストリストの作成
・テストの実装
の2つの物を、分けられない物としているのではないだろうか。
(多分そうなのだと思うけど、アジャイル開発手法にあまり詳しくないので、違うかも)
私の経験上では、たいていの場合は
1. テストリストを作成する
2. 実装する。
3. テストを実装する。
という順で開発を行うのが、一番効率が良い。
つまり、テストファーストではなく、テストリストファースト。
テストを先に実装してしまうと、実装方法や計設が変わってテストを作り直しになってしまう場合に、ロスが大きい。
google-code-prettify
2009-05-22
2008-07-22
結合テストは単体テストよりも先に行うべき
正確に言うと、結合テストのスタートは、単体テストの作り込みよりも前に行うべき。
粘土造形で例えると、単体テストと結合テストは以下のようになる。
単体テスト:
細かいディテールを作り込む。大まかな形が正しく作成されている事が前程となる。
結合テスト:
粘土で大まかな形を作る。他とのバランスも考える。
結合テストの結果次第では、既に作成したモジュールの大幅な作り直しが必要になる事がある。
そのため、単体テストでテストの作り込みを行った後にモジュールの作り直しを行うと、それまで作った単体テストが無駄になる可能性がある。
粘土造形で例えると、単体テストと結合テストは以下のようになる。
単体テスト:
細かいディテールを作り込む。大まかな形が正しく作成されている事が前程となる。
結合テスト:
粘土で大まかな形を作る。他とのバランスも考える。
結合テストの結果次第では、既に作成したモジュールの大幅な作り直しが必要になる事がある。
そのため、単体テストでテストの作り込みを行った後にモジュールの作り直しを行うと、それまで作った単体テストが無駄になる可能性がある。
2007-11-07
デバイスドライバのコードレビューは、ハード担当者にしてもらおう
なぜこんな単純な事に今まで気付かなかったのだろう。
デバイスドライバのコードレビューを行う時、ハードを作ったハードエンジニアにレビュアーの一人になってもらうと良い。
特に、自社でFPGAのロジックを作って、そのデバイスドライバを書く場合は。
今まで、ソフトウェアのレビューは他のソフトエンジニアにお願いしていたのだが、ハードエンジニアがレビュアーとしてふさわしい理由は多々ある。
・ハードエンジニアは、そのハードの動作を熟知している。
・ソフトエンジニアは、ハードの動作を熟知するのが難しい。なぜなら、ハードウェアは「ドキュメント化されていない動作を、ソースを見て動作を理解する」事ができないので。
・ドライバを作っていないソフトエンジニアが、ハードの動作を熟知するのはさらに難しい。特にハードに癖がある場合は。
デバイスドライバのコードレビューを行う時、ハードを作ったハードエンジニアにレビュアーの一人になってもらうと良い。
特に、自社でFPGAのロジックを作って、そのデバイスドライバを書く場合は。
今まで、ソフトウェアのレビューは他のソフトエンジニアにお願いしていたのだが、ハードエンジニアがレビュアーとしてふさわしい理由は多々ある。
・ハードエンジニアは、そのハードの動作を熟知している。
・ソフトエンジニアは、ハードの動作を熟知するのが難しい。なぜなら、ハードウェアは「ドキュメント化されていない動作を、ソースを見て動作を理解する」事ができないので。
・ドライバを作っていないソフトエンジニアが、ハードの動作を熟知するのはさらに難しい。特にハードに癖がある場合は。
登録:
投稿 (Atom)