狠狠撸

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

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

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

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

そして
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 な?leに定義する = 他でも使いまわす
step_fors :hoge {} なnamespaceに定義する
※moduleで分けてもいいけど、eachとかして全部いれるちゃうじゃない？

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

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

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

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

狠狠撸

Acceptance testは開発者か?つくるへ?き(公開版)

More Related Content

Acceptance testは開発者か?つくるへ?き(公開版)