Acceptance Test はテスターが後からつくったらいいとかいう話についカッとなってつくったスライド

1. Acceptanceなtestは
開発者がまず書こう
!
muryoimpl
1

2. ※注意※
ここでいうAcceptance testは
自動テストとして実行できるものを
大前提としています

3. Acceptance Testとは
• いわゆる受け入れテストというやつ
• Web開発者のコンテキストでは、作ったものが
ブラウザの動きをシミュレートして End to end
な感じでちゃんと動くかどうか、を確認するテ
スト(と思っている)
• 有名どころgemでは cucumber とか turnip
feature ファイル作って自動実行する

4. システム
↓
→ Unit test ←
↑
(内部から¦内部の) 動作が正しいかを検証
Unit test
↓
→ Unit test ←
↑

5. システム
外側から動作が正しいかを検証
Acceptance test
↑
Acceptance test
Acceptance test
↓

6. テスト粒度
小 大
Unit test Acceptance test
1つあたりの網羅性
大小

7. さて、本題

8. テスターが別にテスト
作ったらいいじゃん

9. (ﾟДﾟ)ﾊｧ?？

10. なぜ開発者がまず
作成するのか？

11. 開発者にとって
必要だからです
( ｰ`дｰ́)ｷﾘｯ

12. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

13. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

14. 1. 動作異常(バグ)に気がつく機会が増える
• model と controller だけでなくview 側の異常
に気づくことができる
-> poltergeist だと js エラーも検知できるし
-> view spec 作るより幸せだと思うし
• 各ロジック確認するより、feature みるほうが
ざっと何してるかわかりやすいので、
実装漏れに気づきやすい(実際にあった話)

15. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

16. 2. 手動確認の手間が減る
• 苦労が美談的なものは窓から投げ捨てよう！
楽して別のところに時間使おう
• Jenkinsおじさんに任せることもできる
• リファクタリング時、仕様変更時に威力大

17. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

18. 3. feature はリファクタリングのトモダチ
• リグレッションの確認動作が楽チン
-> 手動実行、ダルい。不正確。
-> Q.どこまで確認したらいいの？
A. 迷ったら全部流せばいい
• これが通ればOKという最後の砦ができるので
障壁が下がる -> 積極的にリファクタできる

19. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

20. 3. 一機能としてひと通り動くことを証明できる
• だいたいの仕様を満たすことが確認できると思
うので、一旦「できた」って宣言できる
• 客から求められるのは外から確認できる動きが
正しいか。最低これが正しければ直接確認して
もらうことも可能なのでは？
-> 内部処理が心配なら Unit test を厚く

21. なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる

22. そして
feature あるとですね

23. bundle update
できるようになるんですよ

24. bundle update できるようになる
• RailsやRubyは更新が早い → サポート切れ早い
各種gemをupdateしたときの動作保証は何でする？
-> Unit test カバレッジ100% (ヾﾉ･ ･`)ﾑﾘﾑﾘ
-> feature(外側から見た動きの保証)があれば
道標になる・最後の砦になる
• 2.x系は無理として、3.x系は4.x系にあげたい
-> 開発者は後で「上げて」って言われたときの地獄
を知っている…
-> 使いきりでない限りこれは営業的には確保必至
保守費という概念に含めるべきだが、無理なら
システム寿命を延ばすために絶対必要って言って！
先延ばしにすればするほどコストと不満は激増(真顔)

25. テスターが別にテスト
作ったらいいじゃん

26. (ﾟДﾟ)ﾊｧ?？

27. テスター テストエンジニア
の場合

28. そもそも

29. step定義作成するのに
内部仕様知ってないと
ダメでしょ？

30. どういう仕様か確認しながら
作るより
仕様作りながらstep作るほうが
(私は)楽と思う

31. 楽 == 工数少ない
(心理的にも楽と思う)

32. というわけで

33. feature/stepを
せっせこ開発時に
作りましょう

34. ただし

35. stepのノウハウ貯めるのに
最初はコストがかかる

36. けど、これは醸成する価値
がある箇所だと思います

37. stepのノウハウ
• プロジェクト間で再利用が可能
-> 醸成していけば、後に始まったプロジェクト
は効率化される
• stepが多くなれば、開発者じゃない人たちが
featureファイル作成してテスト作るのも可能に
なる…と思う…

38. stepのノウハウ
抽象度
低
高 common なfileに定義する = 他でも使いまわす
step_fors :hoge {} なnamespaceに定義する
※moduleで分けてもいいけど、eachとかして全部いれるちゃうじゃない？

39. stepのノウハウ
抽象度
低
高 common なfileに定義する = 他でも使いまわす
step_fors :hoge {} なnamespaceに定義する
※moduleで分けてもいいけど、eachとかして全部いれるちゃうじゃない？
なるべく抽象度高くできるといいよね！
※テーブルも使ったほうが見やすいかな

40. 定義貯めたcommonなstepを
ライブラリ的に入れるもよし
!
使うものだけ入れるもよし

41. テスター = テストエンジニア
の場合

42. システムが出来上がった後に
テストエンジニアがテストする観点
って
そもそもシステムがある程度ちゃんと
動いてないとテストエンジニアの
やりたい観点のテストまで到達しないので
もったいないと思う

43. 劇終