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

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

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

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