JaSST'14北海道レポート① - nemorineのブログ

早速、JaSST'14北海道のレポート①を書いてみた。

和田さんの基調講演

目指すものは「動作するきれいなコード」 by ロン・ジェフリーズ
これはTDDを実施している開発者もテストエンジニアも同じ思い。

テスト駆動開発とは？

和田さんによるテスト駆動開発の説明があった。
今回はTDDを全く知らない人も参加者にいるので、かなり丁寧な説明をしてくれたと感じた。

コードを書かないとわからないことが多い
綺麗な設計をしてから！ではなく、動かしてからきれいにする
重要なのはテストがある状態でのリファクタリング。

FizzBuzz問題のデモ

実際にFizzBuzz問題をt_wadaさんがデモしながら、TDDの話をしてくれた。

仕様をToDoリストに変更する。→ 個人的にはポイントだと思う。
テストクラスの名前にはTestxxx と xxxTestの2流派ある
日本語でテストのメソッド名を書く → 日本で開発している場合はかなり有用
初めての場合はテストコードはゴールから考えていく
テストコードのテストは実装コード。お互いにテストしあう関係
実際にテストで値を入れることで気づくことがある
二つ目のデータが正しいコードを導く（三角測量）

三重ループ

Why 頻繁なリリースとデモ
What アクセプタンステスト
How ユニットテスト

TDDの導入効果

MSやIBMの論文の事例の紹介。

TDDで欠陥は６割〜７割減る
実装時間は２割~３割増える

テスト駆動開発を導入することで、プログラミングレベルの
軽微なバグっていうのは無くなる。
TDDを実施した後で出るバグは本質的なバグ。それに対処する。

ユニットテスト自動化してれば品質大丈夫！っていう人が多いので、和田さんにズバっと言ってもらって嬉しいなぁ〜

テストは品質を上げない

体重計を買っただけでは痩せないように、
テストでは品質を上げることはできないので、
品質を上げるためにはコードを修正する必要がある。
テストはあくまでもキッカケに過ぎない。

これは…身をもって体験してるｗ
体重計に乗ってるだけじゃ全く減らないorz

改善を我慢しなくても良い

以前は動いてるコードは触らないということで品質を保っていた。  
今は自動テストがあるので改善（リファクタリング）を我慢しなくてもいい。  
対象のソフトウェアの動作が変わったら、テストが教えてくれる。

やっぱり「動作しているコードを触らない』という方針だけだと機能追加には耐えられないだろうなぁ。常にDRYを意識しながらコードを書いていきたい。。。

開発とテストの人はもっと一緒になろう

TDDだけやっていれば品質があがるかというとそうではない。  
やはり第三者の視点というのが必ず必要になる。  
開発の人とテストの人が一緒にやることでもっと良いものを作ることができる。

本来、開発者とテストエンジニアは共通の目標があるはずなのに、いがみ合っていることが多い。でもそんなんじゃいいもの作れないよね。

感想

今回のJaSST北海道は基調講演に和田さんをお呼びしたことで、開発者からみた品質、テストの話を聞くことができた。JaSST東北でも関さんに来ていただいたので、JaSST東北〜JaSST北海道は開発者視点のテストという流れが繋がった感があってちょっと嬉しい。
和田さんの最後のメッセージにもあるように、開発者はテストの方へ、テストエンジニアは開発者に近づいていく必要があると思う。そしてお互いが交流することで知識の移転が行われるんだろうなぁ。
TDDだけで品質を担保することはできないし、テストだけで品質を上げることはできないから。