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をライブラリ的に入れるもよし

!

使うものだけ入れるもよし

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

システムが出来上がった後に テストエンジニアがテストする観点

って そもそもシステムがある程度ちゃんと 動いてないとテストエンジニアの

やりたい観点のテストまで到達しないので もったいないと思う

劇終