Download - Acceptance testは開発者がつくるべき(公開版)
![Page 1: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/1.jpg)
Acceptanceなtestは開発者がまず書こう
!
muryoimpl
1
![Page 2: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/2.jpg)
※注意※ ここでいうAcceptance testは
自動テストとして実行できるものを 大前提としています
![Page 3: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/3.jpg)
Acceptance Testとは• いわゆる受け入れテストというやつ
• Web開発者のコンテキストでは、作ったものがブラウザの動きをシミュレートして End to end な感じでちゃんと動くかどうか、を確認するテスト(と思っている)
• 有名どころgemでは cucumber とか turnip feature ファイル作って自動実行する
![Page 4: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/4.jpg)
システム↓ → Unit test ←
↑
(内部から|内部の) 動作が正しいかを検証
Unit test
↓ → Unit test ←
↑
![Page 5: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/5.jpg)
システム
外側から動作が正しいかを検証
Acceptance test
↑ Acceptance test
Acceptance test ↓
![Page 6: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/6.jpg)
テスト粒度小 大
Unit test Acceptance test
1つあたりの網羅性大小
![Page 7: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/7.jpg)
さて、本題
![Page 8: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/8.jpg)
“テスターが別にテスト作ったらいいじゃん”
![Page 9: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/9.jpg)
(゚Д゚)ハァ??
![Page 10: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/10.jpg)
なぜ開発者がまず 作成するのか?
![Page 11: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/11.jpg)
開発者にとって 必要だからです ( ー`дー́)キリッ
![Page 12: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/12.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 13: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/13.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 14: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/14.jpg)
1. 動作異常(バグ)に気がつく機会が増える
• model と controller だけでなくview 側の異常に気づくことができる-> poltergeist だと js エラーも検知できるし-> view spec 作るより幸せだと思うし
• 各ロジック確認するより、feature みるほうがざっと何してるかわかりやすいので、 実装漏れに気づきやすい(実際にあった話)
![Page 15: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/15.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 16: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/16.jpg)
2. 手動確認の手間が減る
• 苦労が美談的なものは窓から投げ捨てよう!楽して別のところに時間使おう
• Jenkinsおじさんに任せることもできる
• リファクタリング時、仕様変更時に威力大
![Page 17: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/17.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 18: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/18.jpg)
3. feature はリファクタリングのトモダチ
• リグレッションの確認動作が楽チン-> 手動実行、ダルい。不正確。 -> Q.どこまで確認したらいいの? A. 迷ったら全部流せばいい
• これが通ればOKという最後の砦ができるので障壁が下がる -> 積極的にリファクタできる
![Page 19: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/19.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 20: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/20.jpg)
3. 一機能としてひと通り動くことを証明できる
• だいたいの仕様を満たすことが確認できると思うので、一旦「できた」って宣言できる
• 客から求められるのは外から確認できる動きが正しいか。最低これが正しければ直接確認してもらうことも可能なのでは?-> 内部処理が心配なら Unit test を厚く
![Page 21: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/21.jpg)
なぜ開発者に必要か
1. 動作異常(バグ)に気がつく機会が増える
2. 手動確認の手間が減る
3. feature はリファクタリングのトモダチ
4. 一機能としてひと通り動くことを証明できる
![Page 22: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/22.jpg)
そして feature あるとですね
![Page 23: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/23.jpg)
bundle update できるようになるんですよ
![Page 24: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/24.jpg)
bundle update できるようになる• RailsやRubyは更新が早い → サポート切れ早い 各種gemをupdateしたときの動作保証は何でする?-> Unit test カバレッジ100% (ヾノ・∀・`)ムリムリ -> feature(外側から見た動きの保証)があれば 道標になる・最後の砦になる
• 2.x系は無理として、3.x系は4.x系にあげたい-> 開発者は後で「上げて」って言われたときの地獄 を知っている…-> 使いきりでない限りこれは営業的には確保必至 保守費という概念に含めるべきだが、無理なら システム寿命を延ばすために絶対必要って言って! 先延ばしにすればするほどコストと不満は激増(真顔)
![Page 25: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/25.jpg)
“テスターが別にテスト作ったらいいじゃん”
![Page 26: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/26.jpg)
(゚Д゚)ハァ??
![Page 27: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/27.jpg)
テスター ≠ テストエンジニアの場合
![Page 28: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/28.jpg)
そもそも
![Page 29: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/29.jpg)
step定義作成するのに 内部仕様知ってないと
ダメでしょ?
![Page 30: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/30.jpg)
どういう仕様か確認しながら 作るより
仕様作りながらstep作るほうが (私は)楽と思う
![Page 31: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/31.jpg)
楽 == 工数少ない (心理的にも楽と思う)
![Page 32: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/32.jpg)
というわけで
![Page 33: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/33.jpg)
feature/stepを せっせこ開発時に 作りましょう
![Page 34: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/34.jpg)
ただし
![Page 35: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/35.jpg)
stepのノウハウ貯めるのに 最初はコストがかかる
![Page 36: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/36.jpg)
けど、これは醸成する価値がある箇所だと思います
![Page 37: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/37.jpg)
stepのノウハウ
• プロジェクト間で再利用が可能-> 醸成していけば、後に始まったプロジェクト は効率化される
• stepが多くなれば、開発者じゃない人たちがfeatureファイル作成してテスト作るのも可能になる…と思う…
![Page 38: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/38.jpg)
stepのノウハウ抽象度
低
高 common なfileに定義する = 他でも使いまわす
step_fors :hoge {} なnamespaceに定義する※moduleで分けてもいいけど、eachとかして全部いれるちゃうじゃない?
![Page 39: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/39.jpg)
stepのノウハウ抽象度
低
高 common なfileに定義する = 他でも使いまわす
step_fors :hoge {} なnamespaceに定義する※moduleで分けてもいいけど、eachとかして全部いれるちゃうじゃない?
なるべく抽象度高くできるといいよね!※テーブルも使ったほうが見やすいかな
![Page 40: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/40.jpg)
定義貯めたcommonなstepをライブラリ的に入れるもよし
!
使うものだけ入れるもよし
![Page 41: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/41.jpg)
テスター = テストエンジニアの場合
![Page 42: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/42.jpg)
システムが出来上がった後に テストエンジニアがテストする観点
って そもそもシステムがある程度ちゃんと 動いてないとテストエンジニアの
やりたい観点のテストまで到達しないので もったいないと思う
![Page 43: Acceptance testは開発者がつくるべき(公開版)](https://reader036.vdocuments.pub/reader036/viewer/2022081404/55a09d7b1a28ab656a8b480c/html5/thumbnails/43.jpg)
劇終