なごやかJava ゆるふわテストツール編の発表資料です。

1. テストの自動化を考える前に
bleis-tift
January 11, 2015

2. 自己紹介
id:bleis-tift / @bleis
なごやではたらくゆるふわ Fer
最近の Java はわからない人
言語仕様であればそれなりに

3. 今日話さないこと
特定のツールに関する話
特定の言語に過度に依存した話
各話題の詳細

4. 今日話すこと
テストの自動化を考える前に
考えてほしいことについて

5. 前職で実際にあった出来事
マネージャ 今回はテストファーストでやります
ぐるぐる はい！
マネージャ なので、実装に入る前に
テスト仕様書を完成させます
ぐるぐる はい？
マネージャ テスト仕様書は実装開始までに
Fix され、以降の変更は認めません
ぐるぐる はいぃぃぃぃ？

6. 不幸になるパターン
現状のコードのまま自動単体テストを
追加しようとする
とりあえず、単体テスト (画面のテスト) から
自動化する
自動化の労力を軽視した状態で
自動化を推し進める

7. 現状のコードのまま自動単体テストを追加？
画面から DB まで結合したクソコード
テストコードを追加できないコード
テストコードが書きやすいコードを書くのは
難しい
現状のままで自動化できるとは思わないこと！

8. どうすればいいか
テストコードが書きやすいコードを勉強し、
実践しよう！

9. テストコードが書きやすいコードの勉強
Java であれば、オブジェクト指向プログラミング
その他の言語は今日はいいでしょう

10. テストコードが書きやすいコードの実践
テストコードを先に書く
後から書く？そんな時間作れない
TDD の実践

11. 既存のコードにテストコードを
書きたい場合は？
しかも、テストコードが書きにくい場合は？
テストコードが書けるように変更
してからテストを書く？
それでコードを壊してしまったら・・・

12. どうすればいいか
立ち向かう意義があるかどうか考える
あるなら、武器を増やし、
人数をそろえて立ち向かう

13. レガシーコードに立ち向かう意義
どちらのデメリットの方が大きいか考える
コードを壊してしまうこと
テストコードがない状況が今後続くこと
前者の方が大きい場合はあえて立ち向かう必要は
ないのでは？

14. レガシーコードと戦う武器

15. 人数をそろえる
Q. コードを壊してしまう可能性を下げるには？
A. 常にペアで作業しましょう
他にも、統合テスト等を自動化してから、
それを安全ネットにして進めるという方法も
併用できるなら併用する

16. とりあえず、
単体テスト画面のテスト から自動化？
画面のテストはテストの自動化の中でも
難しい部類に入る
ちょっとした仕様変更で、
大量のテストを直す羽目に・・・
タイミングが絡むと少ない量でも実行時間が・・・
(主に工数的に) 痛い目を見て、テスト自動化
に拒絶反応を示すようになったら最悪
画面のテストは難しいので、
最初に手を出すのはやめておこう！

17. 何から手を出すのがいいか
画面のテストより
粒度の小さいテストから始めましょう！

18. 粒度の小さいテスト
JUnit 等の単体テストのためのツールでやる
ようなテスト
一つの画面単位のテストを「単体テスト」と
呼ばないようにする
(政治的な理由等で) 難しいなら、JUnit 等で
やるテストを「ユニットテスト」とかして分
ける

19. そもそもの話
画面ありきで開発するスタイルを見直してみると
いいかも？
画面ありきの開発スタイルは DDD 本にある
「Smart UI アンチパターン」に陥りやすい
今までのやり方を変え、ドメインモデルを
構築
テストは、ドメインモデルに対してやる
ロジックに関するテストを
画面のテストでやらない

20. 自動化の労力
テストの自動化には労力が必要
今まで見てきたとおり、そもそもテストの自動
化は簡単ではない
更に、自動化のための作業自体も多い
単体テストであればテストコードを書く必要がある
これを軽く見ていると、思ったより効果がな
いと感じる
「大変な割にあまり効果なかったから、
次からは今まで通りで」
闇雲に自動化せず、
効率も考えて自動化の戦略を立てよう！

21. チームの状況は様々
そもそも、誰もテストの自動化をしたことが
ないチーム
実力が低く、NPE などのバグばかり
出しているチーム
綺麗なコードは書けるが、仕様と違う動きを
出すことが多いチーム
などなど

22. 誰もテストの自動化をしたことがないチーム
いきなり実プロジェクトでやるのはリスクが
高すぎる
誰かが自動化を勉強してからにする
そのための時間を作ってもらえるようにする
働きかけ
テスト自動化の重要性をひたすら上に説くとか

23. 実力の低いチーム
単体テストに重点を置く
NPE などのバグを早期解決できるようにする
バグを埋め込んでから見つけるまでの時間が
早ければ早いほど、修正にかかるコストは
低い

24. 仕様と違う動きを出してしまうチーム
統合テストやシステムテストに重点を置く
仕様との差異をチェックできる仕組みの構築
もちろん、ハードルは高い

25. まとめ
現状、テストの自動化は簡単とは
言えないので心してかかりましょう
テストの自動化を
より気軽にできる世界にしたいものです

26. おわり