プロジェクト開始時点で検討しておきたい画面テスト手法

最近のテスト自動化環境について調査。（画面テスト編）

##■単体テスト
単体テストを導入する意味：
    ①変更を加えた際に、テストコードがあると比較的安全に編集ができる。
    ②品質を常に高めていくようにテストコードを記載していくと最後に品質を担保するより作りこめる。

xUnitのようにテストケースを記述できるJavaScriptテストフレームワークを紹介する。

###Jasmine (Framework / Assertion / Spy and Mock)

    http://jasmine.github.io/
    http://qiita.com/opengl-8080/items/cf3acafda9756f4b04c9
    JavaScriptで簡潔に単体テストを記述する事ができる。
    特徴：Spy, Mockも作れる。
    Test Runnerである Karma も一緒に使いたい。
    http://qiita.com/hosomichi/items/311e3eac4f55183b62c2

###Mocha(Framework)

    必要になったらライブラリを追加して使っていく汎用的なフレームワーク。
    Assertionを入れる際にはchai.jsを入れる
    モックを作る際にはsinon.jsを入れる
    TDD(be)・BDD(should be)の両方が利用できる。

###QUnit, JsUnit
    -> Framework + Assertion
    最近見かけないけど、歴史があるフレームワーク。

##■結合テスト
結合テストフェーズにおいては、各種ブラウザでも挙動が正しいか確認を行うために、ブラウザを実際に操作するツールを利用するのが望ましい。

###Selenium WebDriver

    http://totech.hateblo.jp/entry/2014/03/05/181454
    「ブラウザを起動して～テキストを入力して～ボタンを押す」といったブラウザの動作をスクリプトで制御できる。
    実行するとブラウザが起動して、スクリプト通りにブラウザが動くのを見ることが出来る。
    1つスクリプトを作ると複数のブラウザで テスト出来る（IE / FF / Chrome / Opera / Safari / Chrome in Android）
    スクリプトはJava / Python / Ruby / C#で記述する。 
    スクリプトを書くのが辛い時には、Selenium IDEを使いキャプチャを取ってコードを自動生成する。（細かいコードの修正は必要）

###capybara

    http://qiita.com/jnchito/items/607f956263c38a5fec24
    Selenium（Java）のRubyラッパー。最近ドキュメントが揃ってきた。
    gemコマンドだけで準備が出来るため環境構築が簡単。

###PhantomJS

    コンソールのみでwebkitブラウザを操作する。
    画面は出てこないがキャプチャを取ることができる。
    実行環境を選ばずにスクリプトで動作を制御できる、という点が大きな利点。
    なので、WindowsやMacのみならず、CentOSやUbuntuなどのLinux系のOSでも動作できる。各種ブラウザのインストールも不要。
    その特性上、ブラウザ間の挙動の違いを検知することが出来ない。例えば、IEの場合のみ動作しないJavaScriptとかは分からない。

##■CI

    自動テストの実行環境としてCIツールを紹介する。
    CIツールを使って、①テスト＋ビルド＋デプロイの自動化をしてタスクを減らす②メトリクス分析を使ってコードの品質状態を常に把握する
    上記2点だけでもやっておくとプロジェクトのTCOを削減できると感じている。CIを入れることを是非勧めたい。

###Jenkins

    https://jenkins-ci.org/
    我々のチームで用意しているJenkinsを利用して、次のメトリクス情報を取得することが出来る。
    ・Checkstyle warnings
    ・FindBugs warnings
    ・静的解析
    ・Coberturaカバレッジ・レポート
    自動ビルド（Jenkinsの活用）
    既に活用準備が出来ているため環境構築コストが低く、また新たに準備するものもビルドスクリプト程度で済む。

・メトリクス分析ツールであるSonar が SonarQubeに変わっていた。

    ステップカウント・重複度（コピペコード発見）・複雑度の解析が出来る。問題がある所はドリルダウンして確認していく。
    http://www.slideshare.net/masakkuma/sonar-qube

###CircleCI

    https://circleci.com/
    CIツールの運用管理をアウトソースしたいときに利用したい一方、リポジトリが社外にあるためソースコード管理要件が厳しいときには使えない。
    circle.ymlをプロジェクト内に入れておくと、ビルド制御ができる。
これにより属人的なJenkins職人が管理するより各領域の専門家がコミットしていくフローに切り替えやすい。

###Travis CI
    https://travis-ci.org/
    Circle CI と近い。

##■負荷テストツール
クライアントPCからサーバーに対して複数のリクエストを投げる事ができる。多量のリクエストを投げることによって、サーバーに負荷をかけるツールとして負荷テストツールを利用する。

###gatling
http://gatling.io/#/
Scalaによる内部DSLを記述する。JMeter同様シナリオの自動生成もできる。
Analyze画面がカッコイイ。Jenkinsとの相性が良い。
欠点は起動が遅い所。

###Oracle Application Testing Suite
http://www.oracle.com/technetwork/jp/oem/app-test/etest-101039-ja.html
良品ではあるが、何をしても動作が遅いのが難点。

###JMeter

    一番使われているツールと思われる。
    http://jmeter.apache.org/
    JMeterを使うなら、Googleのプラグインを入れるといろいろ捗る。http://jmeter-plugins.org/


##■まとめ

    使えると思っているのは、①Jasmine + Karma + Selenium + Jenkins
    最近Web系会社でよく見かける組み合わせは、mocha(+ chai.js + sinon.js) + phantomJS + Circle CI( or travis-ci)

##■参考にしたページ
１．JavaScriptのテスト環境の参考URLメモ(2015-03時点)
http://hblog.glamenv-septzen.info/entry/2015/03/30/005813
２．mochaとphantomJSとtravis-ciでフロントエンドJavaScriptのテスト
http://webtech-walker.com/archive/2012/10/mocha_phantomjs_travisci.html
３．Jenkins ユーザ・カンファレンス 2015 東京に行ってきた
http://totech.hateblo.jp/entry/2015/01/11/215628
4.TDD & CI for JavaScript [Karma][Mocha][Travis CI]
http://inet-lab.naist.jp/blog/wp/wp-content/uploads/2014/09/test-tools.png