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