Download to read offline
Uploaded byKen Muryoi
Acceptance testは開発者がつくるべき(公開版)
Acceptance Test はテスターが後からつくったらいいとかいう話についカッとなってつくったスライド
More Related Content
Acceptance testは開発者がつくるべき(公開版)
- 1.
- 2.
- 3. Acceptance Testとは • いわゆる受け入れテストというやつ •Web開発者のコンテキストでは、作ったものが ブラウザの動きをシミュレートして End to end な感じでちゃんと動くかどうか、を確認するテ スト(と思っている) • 有名どころgemでは cucumber とか turnip feature ファイル作って自動実行する
- 4. システム ↓ → Unit test← ↑ (内部から¦内部の) 動作が正しいかを検証 Unit test ↓ → Unit test ← ↑
- 5.
- 6. テスト粒度 小 大 Unit testAcceptance 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.
- 23.
- 24. bundle update できるようになる •RailsやRubyは更新が早い → サポート切れ早い 各種gemをupdateしたときの動作保証は何でする？ -> Unit test カバレッジ100% (ヾﾉ･ ･`)ﾑﾘﾑﾘ -> feature(外側から見た動きの保証)があれば 道標になる・最後の砦になる • 2.x系は無理として、3.x系は4.x系にあげたい -> 開発者は後で「上げて」って言われたときの地獄 を知っている… -> 使いきりでない限りこれは営業的には確保必至 保守費という概念に含めるべきだが、無理なら システム寿命を延ばすために絶対必要って言って！ 先延ばしにすればするほどコストと不満は激増(真顔)
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 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.
- 41.
- 42.
- 43.