読者です 読者をやめる 読者になる 読者になる

ソフトウェア・テストPRESS総集編にて記事執筆

 先日、ソフトウェア・テストPRESS総集編で「始めてみよう! 検証指向TDD」という記事を執筆させて頂きました。

書籍案内:ソフトウェア・テストPRESS総集編|gihyo.jp … 技術評論社

 内容としては「検証指向TDD」という名前を付けているものの、基本的に自分がTDDの中できちんとしたテストを書くために心がけていることを書かせて頂いています。また恐縮ですが、今回の特集では前後の第一章・三章でも、結構な割合で文章執筆や内容考案をやらせて頂きました。


 なお今回はテストエンジニア向けのテストPRESSに記事掲載させて頂いていますが、問題提起としてあえてプログラミング(テストコードの実装)の解説にそれなりの字数を割いています。これは「テストの堅牢性や保守性の確保には、テストの構造的設計の工夫、テスト実装の工夫による下支えが不可欠である」という思いを重視した結果です。

 実際問題、テスト設計の工夫で(保守性等も含む)テストの品質を改善させても、記法や粒度が混乱したEXCEL手順書の山を積み上げる、コピペだらけのテストコードを作るなど、テスト実装をいい加減に行えば、それら改善効果は大きく損なわれてしまいます。一方でテスト設計の手法や方法論の多くは、テスト観点やテスト対象の分割、テスト仕様といったものに焦点を置き、テストの構造的設計(テストコードやテストスクリプト、テスト手順書等といった、テスト実装成果物の構造的な設計)にはあまり触れていないため、なおさらテスト実装で工夫できる余地が残っていると感じています。
 また近年はTDDといったユニットテストの方法論の広がり、FitNesseやCucumberといったコード・スクリプトでテストを実行するツールの普及、データ駆動テストやTest Doubleといったテストの構造的設計パターンの充実により、テストの構造的設計・テスト実装で工夫できる領域が日々広がっていると感じています。今回の記事では、そうした領域での改善で堅牢なテスト構築を支えられれば、というものをねらいの1つとしています。
 その他、twitter等で頻繁に議論されているTDDと一般的な単体テスト工程の観点の違い等の話題にも触れていますので、興味のある方は手に取っていただければと思います。