スローテストとTDD
XP祭り関西2011で井芹さんのTDDの話を聞きながら、改めてTDDの奥深さを実感した。
そして、僕が常日頃感じているスローテストについても考えてみた。
以下メモ書き。
【元ネタ】
DevLOVE-CI「たとえ世界が終ろうとも、僕はビルドをケイゾクする。」へ行ってきた - 虎塚
第3回 社外常駐で学んだアジャイル開発 | Think IT
[Agile][資料公開]DevLOVE Test Dayでお話しました #devlove | Ryuzee.com
DevLOVE Test Day に行ってきました #devlove - かおるんダイアリー (id:kaorun55)
スローテストとは「テスト・コードが多すぎて、すべて実行するのに時間がかかる」という問題。
TDDをちゃんとやっていくと、動くシステムのLOCよりもテストコードのLOCが10倍ぐらい増える。
すると、コミットする度にビルドすると時間がかかりすぎるし、夜間ビルドですら終わらなくなる。
ビルドが遅くなるということは、製品化する時間が長くなるということなので、Agileでないし、開発者もCIを実施してくれなくなる。
井芹さんにスローテストについて質問したら、DBにアクセスする部分をモック化したり、並行ビルドしてみたり、テスト環境を仮想化したり、色々やり方はありますよ、と聞いた。
僕はスローテストの問題は、まだまだ改善の余地があると思っている。
井芹さんの講演では、TDDでも可読性や保守性を高めるためにリファクタリングは必要であるという主張がずっと根底に流れていた。
テスト技法の解説書として、秋山さんの「ソフトウェアテスト技法ドリル―テスト設計の考え方と実際」や「はじめて学ぶソフトウェアのテスト技法
」が紹介されているのには驚いた。
色々勉強されているなあという感想を持った。
TDDであろうとも、肝心のテストケースは既に知られている各種技法を使った方がテストの効率も生産性も上がる。
TDDでは普通とは異なるプログラミング技法がある点も技術者としては興味深い。
モックやリフレクション、メタ言語などがそれに当たるだろう。
「xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))」の本とその勉強会のログも紹介されていたので、調べてみたいと思う。
| 固定リンク
「ソフトウェア工学」カテゴリの記事
- 因果ループ図を再考する~問題の症状をシステム構造として捉えて解決策を見つける(2020.12.25)
- 第73回 SEA関西プロセス分科会「モデルベースシステムズエンジニアリングの活用」の感想~モデルの検証を形式手法で自動テスト化する(2020.12.13)
- 相殺フィードバックを再考(2020.06.17)
- SaaSのビジネスモデルがアジャイル開発を促進したという仮説(2020.06.14)
- なぜなぜ分析、FMEA、FTAの違い(2020.06.09)
「Agile」カテゴリの記事
- 文化は組織構造に従う(2021.01.19)
- 「ストーリーマッピングをはじめよう」本の感想~ストーリーによる企画や要件定義はSaaSと相性がいい(2021.01.17)
- 管理職に求められる能力はPM理論そのものではなかったのか(2021.01.14)
- yWriterは映画の脚本を作るためのアプリだったのではないか(2021.01.05)
- カンバンはステータス名が大事(2021.01.02)
コメント