詳解！自動結合テスト #jasst

Web Automate Integration Testing

詳解！自動結合テストkyon_mm

2013/11/1 jasst’ 13 Kyushu

自己紹介

きょん(@kyon_mm)

ソフトウェアテストアーキテクト

うさみみ系エンジニア

Groovy, C#, F#, Ruby, Scala

SCMBootCamp, TDDBootCamp, 基礎勉強会, Nagoya.Testing, Cafe.Testing, STAR, TDDeXchange

アジェンダ

私の背景(Webアプリ中心とかチームが優秀とか)

品質を保つ自動テスト(どの立場で関わるのか大切）

テスト設計について(共有しやすい形とか）

詳細はイブニングセッション！

取り組み方（Groovy系, C#系, Scala系）

詳細はイブニングセッション！

私の背景

開発対象

.NETで動くサーバーサイドのメッセージ型のWebアプリケーション。RESTfulAPI的な。

たまにGUIもあり。

HTTPでXMLとかJSONを交換する感じ。

私の背景

開発規模

1ヶ月から3ヶ月くらいが多い。大きいと1年。

開発人数

社内チームはマネージャー含めて2 - 4人が多い。

他ベンダーと協調して作る事が多い。

私の背景

開発者

優秀だと言い張れるくらいには優秀

お互いを尊敬し合いながら意見交換できる

綺麗なコードが正義であり、自動化された単体テストがないプロダクトはあり得ないという文化

アジェンダ





品質を保つ自動テスト

【まえがき】テストのコスト意識はとても重要です。テストのコスト意識はとても重要です。


テストの自動化は何度も実行しなければもとが取れないとかいう話があります。


自動化は３回やらないと元がとれない？

目を覚ませ。建前はいらないのだよ。


テストの自動化は何度も実行しなければもとが取れないとかいう話がありますが、そういうのは建前です。嘘です。いい訳です。

「結合テスト自動化で得られる最大のメリットはテスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」

「手動では不可能なテストの実装、コストの大幅低減」を実現するのは多くはシステムテストレベルである事が（比較的）多い。


「結合テスト自動化で得られる最大のメリットはテスト実装者が得る幅広いプログラミングスキルとアーキテクチャ知識である」

結合テストレベルの自動化をしなくていいと言っているのは、上のメリットを「(優先順位を考慮して)必要ない」と言っているのと同義だと捉えていると考え直してから決定する。


自動テストを誰かが勝手にやってくれるものとして保証する

自動テストを自分の手足のように使う(理解する)ものとして保証する

自動テストなしで保証する

どの立場でテストを行うかはあなた次第

アジェンダ





テスト設計について

テストプロセスで重要なもの

見積もり

優先順位の変更

実装のスケール

保守

実施のスケール

テスト設計について

EmacsのOrg-Mode表記 (個人的にオススメ

UserStory + 6W2H

マインドマップ (個人的にオススメ

マトリクス

オブジェクト図

アジェンダ





取り組み方

Groovy

Spock : 表形式とコメントを豊富につけられるテスティングフレームワーク

AsyncHttpClient : Httpのクライアントとして高性能な非同期通信ライブラリ

Geb : WebDriverをベースにしたWebGUI操作のテストライブラリ

取り組み方

C#

TestAPI : 因子水準の組み合わせ、豊富な値ランダム生成などを持っているライブラリ

WebHttpClient : 標準のWebClient

NUnit : C# のテスティングフレームワーク

EntityFramework : ORマッパー

取り組み方

Scala

Gatling : HTTPでの性能テストフレームワーク。普通のWebClientなテストフレームワークとしても使える。

ScalikeJDBC : DB操作のためのORマッパー

自動テストの悪用

社内外で自動テストを経験してわかったことが2つある。

自動結合テスト

TDD


結合テストの自動化のROIで実行回数に目がいくのか？

結合テストの自動化で意味があるものは？


結合テストの自動化がうまくいっているとはどういうことか

保守性？

属個人性？


自動結合テストが「うまくいっている」と思い込んでしまうパターンがある。

「無駄なテストを大量に増やせる事」

「効果がありそうなんだけど無駄なテスト」をいかに減らせるかが鍵になってくる。


効果的な自動結合テストとはどうすればつくれるのか？


結合テストを減らすには、結合テストより前の段階でどうやって減らすかにかかっている。

テストで減らす : 結合テストより下のテストと「網羅対象や度合い」をテスト設計する

設計で減らす：結合テストでの因子水準を減らせるようなプロダクト設計する


プロダクトコードをレビューできるスキルがないなら、効果的な自動結合テストは不可能に近い。


効果的な自動テストはなにかを考えないと、「自動化対象外と協調したテスト設計をおろそかにする」

自動化対象のテストのみに着目するので「ROI=予想実行回数」のような発想になる。

自動テストの悪用

社内外で自動テストを経験してわかったことが2つある。


TDD

Definition TDD

1. 失敗するテストコードを実装する

2. テストが通る最低限の実装をする

3. 1と2を繰り返す中で、テストの変更につよくするための実装をする

1 - 3を30secから1minで繰り返す。

TDD

TDDをして品質があがると思う人が多くいる。一方で上がらないと思っている人がいる。

（効果のある品質特性が異なるという話ではないよ。

Good TDD

強制的に検査されたプロダクトしか手に入らなくなる事によって、つまらないバグが減る。

最低限のテスト、最低限のプロダクトのみによって進められるサイクルによって得られる本質に近づくための知識を取得できる。

Bad TDD

あるコミュニティにとってTDDは成功しやすい手法かもしれないが、失敗する場合もある。

例

AdaコンパイラはTDDを採用したが、よろしくないTDDを行ってしまって、今までにないバグを発生させた。

Why Fail

TDDが難しいから？

TDDでカバレッジ100%を目指したから？

自動テストの実行結果がオールグリーンのスクリーンショットをExcelにはったから？

上3つをクリアしても失敗する原因がある

Why Fail

TDDはコードを増やすことになっている。

低スキルなプログラマーが「プロダクト」だとしても「テスト」だとしても書くのは「ひどいコード」であることには変わりない。

でも、意味の通じないドキュメントを書いてしまうことよりはずっとマシ :-p

言い換えれば、TDDで効果があがるのは、属個人性の排除と、意味の通じないドキュメントによって生み出されるバグ予防、確認不足の予防

詳解！自動結合テスト #jasst

Technology