第50回「テスト駆動開発」


気付けばもう50回…
思えば遠くに来たものだ…

 さてさて、今回の勉強会はテスト駆動開発と題して、開発手法の一つである、テスト駆動開発をする上でのメリット・デメリットなんかをデモを交えながらやっていきました。テスト駆動開発はテストファーストで、まずテストコードを書いていってその後プロダクトコードを書くってのが一番の特徴になります。テストがまずは書かれるので、何がしたいのか仕様が明確になるってのと、テストが通っているってことで、コードのリファクタリングがしやすくなるというメリットがあります。でも、当然コードの量が増えるので、短期的に見るとコストが掛かる手法であり、仕様そのものの間違えていたら、テスト結果も間違えますので、バリバリコードが書ける人に取っては面倒くさい手法とも言えます。

単体テストってしていると思うのですが、普段はどのようにやっていますか?

 昔からのソフトウェア会社では、割とエクセルにマトリクス表みたいなのを作成して、1件1件パターンを人間が入力しながらやっていったりしているのがあるのではないでしょうか。このマンパワーを駆使した方法って、NGパターンが見つかったらもう一度やり直ししたり、エビデンスとして画像をエクセルに貼り付けたり、貼り付ける画像がちょっと失敗したらもう一度やり直したり等非常に手間がかかっている事が多かったりします。
 テスト駆動開発とは若干外れるのですが、テスト駆動開発をやる上では、VisualStudioやEclipseなどの統合開発環境にはこういったテスト支援ツールが導入されているので、テストコードを書くことで、こういった処理が自動化出来るので、戻りの手間が少なくなるという副次的な効果もあったります。
 今回のデモでは、Eclipseを使ってJUnitのデモをやってみたり、Seleniumを使ってWebUIテストの自動化のデモをやったりしてみました。JUnitのデモはライブコーディングをしながらやってみましたが、うーん。。。見ているだけで終わってしまった感じがして若干残念な感じがしました。その後、最近のプロジェクトでテスト駆動開発を利用したので、その感想をプロジェクトメンバーから話してもらってディスカッションをしていこうと思いましたが、デメリット面が強く出てしまった感じもして、企画倒れ的な感じになってしまって。難しいですねぇ。。。
 ただ、今後は積極的に導入していきたい手法ではあるので、この機会に触りだけでも感じていただければ良いのかなと思いました。自分自身ももう少しテスト駆動開発をやる上でのスキルを上げていかないといけないかなと実感したり。

それでは今回はこのへんで。
次回もテスト絡みのお話になるかと…。