TDDに必要な技術
TDDを実践するための最低限必要な技術は「モックオブジェクト」「カバレッジ」の2つであると考えるが、意外とハードルが高いのではないか?
その理由を考えてみる。
【1】モックオブジェクトが使えるか?
Webシステムでは、JUnitを純粋に適用したテストプログラムは殆どありえない。例えば、Servlet、EJB、DB接続層等では、どうしてもスタブが必要になる。但し、Servletから業務ロジックを委譲する設計になっていれば、ビジネスロジック層は純粋なJavaのクラスゆえ、ビジネスロジック層のみJUnitがそのまま使える。
だから、モックオブジェクトを使う必然性が出てくるが、スタブを切り替える設計になっていないと、テストプログラムは書きにくい。プログラムをコンポーネントで組み合わせる発想の元に、モデリングや設計を制御することが必要だが、結局はプロジェクトリーダーの手腕にかかっている。
#DIコンテナを使っていれば、すごく簡単になるだろう。
【2】カバレッジを行っているか?
単体テストの進捗を数値化できるので、顧客にもアピールしやすい利点がある。(これは重要!)
しかし、テストケースを単体テストレベルまで細かく落とせるか? テストプログラムのJavaDocがテスト仕様書になる等の仕組み作りが必要だが、その問題解決はプロジェクトリーダーの手腕に依存する。
「テストプログラムがあるから単体テストはクリアしている」というレベルを保つには、少なくとも、モックオブジェクトを使える設計と、テストケースが完全に網羅されていることを保障するカバレッジの2要素が必須ではなかろうか?
しかも、上記2要素を適用するには、プロジェクトリーダーの切り盛りに依存している所に難しさがあるのではなかろうか?
| 固定リンク
「日記・コラム・つぶやき」カテゴリの記事
- Clubhouseは路上ライブや朗読のためのツールかもしれない(2021.04.04)
- ノートパソコンが入ってUSBポートが付属しているビジネスリュックを買ってみた(2021.03.21)
- デブサミ2021の感想~コミュニケーションスタイルがオフラインからオンラインに激変している(2021.02.25)
- 考えながら書く人のためのScrivener入門の感想(2020.12.06)
- 課題は問題点をひっくり返す表現だけで良い場合もある(2020.09.28)
「プログラミング」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- Ruby技術者認定試験の感想(2020.05.08)
- 前処理大全の良いところ~SQLとRとPythonで対比できる(2019.07.10)
- WinSCPでトンネリングする方法のリンク(2018.09.09)
- 仕様書にもExcel脱却が求められている(2017.12.23)
コメント