第38回HTML5とか勉強会 #html5j に行って来ました

• https://html5j.cloudfoundry.com/event/sd38
• 第38回HTML5とか勉強会 - 「Webアプリ×テスト最新事情」 #html5j - Togetterまとめ

多少遅れて行ったので、途中からですけれども。急遽サテライト会場も出来るくらい大盛況だったようです。

JavaScriptテスト最新事情 Why? What? How?

資料 → JavaScript Unit Test Why? What? How?

• なぜJavaScriptでテストを書くのか？
  • 実践アジャイルテスト
    • ビジネス面⇔技術面 の軸
    • チームを支援する⇔製品を評価する の軸
  • 結合テストは左上の領域
    • ビジネス面を支援する、技術面のテスト
    • どんなサービスでも必要
    • 自動化が推奨
  • ユニットテストは左下の領域
    • チームを支援する、技術面のテスト
    • 開発者による開発者のためのテスト
    • 大規模では必須
    • 自動化が必須
  • TDDと黄金の回転
    • 実践テスト駆動開発
    • 2重のフィードバックを回す
• JavaScriptを取り巻く状況
  • 規模も大きくなって、大事になってきている
  • ロジックをJavaScriptで書くことも多くなった
  • テストをする環境も充実してきている
    • node.jsによる恩恵
  • MV*が流行っている
    • モジュール化の仕組みが成熟してきている
  • ユニットテストがしやすくなった
• JavaScriptのテストの難しい理由
  • コードがViewと結びつきやすい
  • どうしてもブラウザで実行されるので扱いづらい
• 解決策
  • コードがViewと結びつきやすい
    • MVCのフレームワークや設計
  • どうしてもブラウザで実行されるので扱いづらい
    • テストツールで解決
• MV*
  • 色々宗派はあるが、やりたいことは、ロジックとビューを分離することである
  • 分離さえ出来てしまえば、ロジックのテストが出来るはず
• 例
  • メール一覧
    • Model:全件取得する、宛先絞り込み、タグで絞込み
    • View：受け取ったリストを表示する
• Modelのテストをしよう！
  • Viewのテストは。。。
    • DOMのテストは書きにくい
    • ユーザビリティのテストは出来ない
    • 画面を見ながら試行錯誤が必要になる
    • ある程度できてきたらテストにチャレンジしてみれば？
• テスト
  • テストツールの分類
    • 実行環境
    • リモートテストランナー
    • テスティングフレームワーク
    • モックライブラリ
• テスティングフレームワーク
  • テストの記述と実行を担当する
  • 成熟してきているのでどれを選んでも間違いはないレベル
• 実行環境が重要
  • 実ブラウザでテスト
    • 本物だけど、面倒くさい、遅い
  • ヘッドレスブラウザ（PhantomJS）
    • WebKitのレンダリング部分を取り除いたもの
    • だいたい本物でそこそこ速い
    • ただし、WebKitだけ
  • シミュレータ（jsdom, envjs）
    • 偽物だけど早い
• リモートテストランナー
  • ブラウザをキャプチャリングして、リモートでテストを実行するツールです
    • 一般的な言葉ではないかも
  • 実ブラウザの欠点を補う
  • 同時に複数のブラウザでTDDが可能
  • Testem、Karma(旧名称 Testacular)、JsTestDriver、Buster.JSなど
• DEMO
  • Jasmine + Testemを使うのが導入が簡単
  • 簡単なFizzBuzz
  • npm install testemで一発でインストール
  • コマンドでテストを実行する
    • TDDする、実行すると、実装が無いのでエラーになる
  • 実装を書いてあげる
    • テストが成功する
  • テストを追加していく
  • 特に設定ファイルとか書かなくても始められるので、お手軽
  • PhantomJSとも連携できる
• それ以外
  • カバレッジ
  • 静的解析
  • Lint
  • 型チェク（Cloure、TypeScript
  • それらをまとめるGruntなど
• まとめ
  • JSでもユニットテストは大事
  • モデルのテストからはじめよう
  • テスト関連ツールの深化がやばい
  • TDDで楽しい開発

いつやるのか？今でしょ！

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects’Archive ソフトウェア開発の実践)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

jasmine

資料 → Unit-Testing With Jasmine // Speaker Deck

• jasmineを使ったユニットテストについて
  • BDDとは？
  • jasmineとは
  • それらについてくわしく
  • jasmineで使えるツール
  • クリスチャンヨハンセンの言葉
    • テスタビリティはグッドデザインである
    • もしテストするのが難しければ、それはコード自体が良くない
  • jasmineはBDDのツールです
• BDDとは？
  • BDDはTDDから派生したもの
  • TDDの混乱や誤解の6個
    • どこから始めるのか
    • なにをテストするのか
    • なにをテストする必要はないのか
    • どの程度テストすれば良いか
    • テストを何と呼ぶか
    • テストが失敗した理由をどう理解するか
  • その回答
    • これから作成しようとしているプログラムに期待されている振る舞いや制約条件を記述する
    • アプリケーション全体ではなく、小さく1つのことのみ記述する
    • テストを文章のように記述する
    • ビジネスの観点を入れる
    • JasmineはBDDをJavaScriptで実践するためのツール
• Jasmineとは？
  • ある仕様に対して、コードがどんな振る舞いをするべきかを表現するのを手助けしてくれるツール
    • RubyのRSpecにインスパイヤされたもの
  • ダウンロードすると、サンプルが含まれている
    • http://pivotal.github.io/jasmine/
    • 初期設定とかをする必要はない
  • Jasmineは本当にシンプル
    • describe: Suite（スィート）と言う
    • it：Spec（スペック）と言う。プログラムの断片がおこなうこと
    • describeの中でdescribeを定義をすることもできる
    • expect：期待される振る舞いを書く。英語の文章のようになる。
    • toEqualのような比較することをMatcherと言う
    • ○○が含まれている場合のMatcherは、toContain
    • Matcherの一覧はドキュメントを参照
• Jasmineについて詳しく
  • Before/After
    • beforeEach() / afterEach()
    • たいていの場合はセットです
  • Async
    • waitsFor
    • 指定の時間まで繰り返す
    • 1000ms以内に値を返さないと失敗とみなすなど
  • SPY
    • Test Double : UTのパターンのひとつ
    • 関数に成り代わって、その関数がどう呼び出されたのかを教えてくれる
    • 関数が呼び出されたか、何回、引数は？など
• Jasmineまとめ
  • Jasmine単体で使えるわりには、色々出来る。
  • Jasmineは歴史があるので、様々な補助ツールがある
• 厳選ツール
  • Jasmine.Async
    • derickbailey/jasmine.async · GitHub
    • MocaをJasmineで使える
  • Jasmine jQuery
    • velesin/jasmine-jquery · GitHub
    • Matcherを提供してくれている
    • Fixtureを呼び出すことも出来る
  • Jasmine-Sinon
    • froots/jasmine-sinon · GitHub
    • SinonのMatcherを提供してくれる
  • Undersocre Matchers for Jasmine
    • raganwald/Underscore-Matchers-for-Jasmine · GitHub
    • underscore.js. backbone.js
  • JavaScript Testing Boilerplate
    • studiomohawk/js-testing-boilerplates at grunt-0.4.x · GitHub
    • Gruntのセットアップを勝手にやってくれるらしい
  • JavaScript-Koan
    • studiomohawk/javascript-koans at ja-translation · GitHub
    • 日本語訳をしているので参考に
• まとめ
  • テストを書くことは、デベロッパーズブロックに解消につながる
    • 文章がかけなくなることをライターズブロックと言う
    • 書くことでしか解決しない
  • ライターが推敲するように、デベロッパーはリファクタリングする
  • そのためにはテストが必要
  • アウトラインをテストで書くことでリファクタリングに強くなる
  • テストがあれば再利用しやすくなる

テスト駆動JavaScript

SinonJS

資料 → Sinon.JS

• SinonJS
  • 神話の中のスパイの名前
• Sinon.JSとは？
  • Test Doubleのライブラリ
  • QUnitやMochaなどと組み合わせて使用する
  • Test Doubleとは？
    • テストしずらい部品をしやすいものに置き換えてテストする
• Spy
  • Queryのtriggerの例
    • 1回しか呼び出されないときは簡単だが、2回呼び出されたことをテストするのは面倒である
    • カウンターとかで判断しなければならないため
  • Spyはその面倒なことを解決してくれるもの
    • スパイオブジェクトを作る
    • スパイオブジェクトは、何回呼び出されたか、どんな引数で呼ばれたかを保持する
    • 通常であればカウンターを使って書いたものが、簡単に表現出来るよ
    • イベントは、発火していなくても通ってしまう不具合等が発覚しづらい
    • 書いた順に呼ばれるので、Spyであれば見やすい
    • callbackは記述の順番と実行の順番が異なるので見にくい
  • 既存のメソッドをSpy化することも出来る
    • jQueryのremoveメソッドをテストするのは面倒である
    • removeをスパイする
    • var spy = sinon.spy(jQuery.fn, 'remove');
    • 既存のメソッドをどのように呼ばれたかがわかるようになる
    • Spyは、書き換えてしまうので、Before,AfterでRestoreする必要がある
• Stub
  • Spyを拡張しているのでSpyの機能を持っている
    • 元の関数を上書きする
    • 例えば、window.confirm等（書き換えないとテストしてられない）
    • スタブでwindow.confirmを上書きする
    • どう振る舞うかを設定することが出来る。例えば、必ずtrueを返す等
• Mock
  • Stubを拡張しているので、Spy、Stubの機能を持っている
  • 予め、どう振る舞うかを定義しておく
  • mock.verify()を呼べば、振るまいが定義した通り動いたかを判定できる
  • MockとStubは同じ事が出来るので、使い分けすれば良い
    • Stubの方がわかりやすいかもしれない
• Fake Timer
  • 日付に関するところが面倒である
    • 日曜日か判定するテストは、日曜日しか通らなくなる
    • UseFakeTimeで、日付を指定する
    • 必ずリストアすること
  • setTimeoutなどのTimerを変えることが出来る
    • 時間を進めることが出来る
    • clock.tick()関数を使う
    • 簡単に、同期的にテストをすることが出来ま
• Fake XHR
  • リクエストがちゃんと飛んでいるかを確認する
    • 通信する部分をまるごと書き換える
  • 別の書き方で、FakeServerもある
    • 比較的直感的になる
• まとめ
  • Sinon.jsとても便利
    • でも、使いすぎには注意しましょう
  • 何でもかんでも、MockやStubにするのはやめておこう
    • 何をテストしているのかわからなくなる
• 宣伝
  • CodeGridのサービスをやっています
    • Sinon.JS
  • 週3回配信
  • 月額840円で、初回1ヶ月は無料

JSテストフレームワークの比較（QUnit、Mocha、Jasmine...）

資料 → Java script testing framework for around html5 studies-

• @IT記事など
  • 「フレームワークで実践！ JavaScriptテスト入門」最新記事一覧 - ITmedia Keywords
  • フレームワークで実践！ JavaScriptテスト入門（1）：JavaScriptテストの基礎知識と使えるフレームワーク6選 (1/3) - ＠IT
• 対象
  • JavaScriptのテストどうしてますか？
    • フレームワーク使ってるの？
    • なにそれ、美味しいの？っておもってる人向けです
• フレームワーク使った方がいい理由
  • テストを繰り返し実行できる
  • 自動化できる
  • バグフィックスやリファクタリングが安心してできる
  • 仕様を見通せる
  • クロスブラウザでテスト出来る
• 導入しよう！
  • でに、フレームワークは意外にいっぱいある
  • さらにバリエーションがある
  • よって、いくつかのフレームワークを比較してみる
• QUnit
  • もともとjQuery用のテストフレームワークであるがｍ現在はJavaScriptの汎用
  • xUnit系に近い書式
  • 同期、非同期をサポートしている
  • APIで外部ツールとの連携も出来る
• Jasmine
  • Pibotal Labsが開発
  • 割愛
• Mocha
  • Expressの作者が作った
  • 非同期系のテストをサポート
  • アサーションライブラリを選択して利用
    • Chaiなど
  • TDD、BDD、exports、QUnitなどの書き方を選択可能
    • デフォルトはBDDのスタイル
  • レポートの書式が豊富
  • 非同期の場合はdoneを呼ぶ
    • 次のテストはdoneを呼ぶまで動かない
• 組み合わせて使う
  • JsTestDriver
    • Googleが作成
    • 1つ以上のブラウザにコマンドラインテスト実行
    • 単体でもxUnit系スタイルでテスト記述も出来る
    • Javaが必要
  • Karma
    • Angular.jsのチームが作成
    • TestRunnerなので、フレームワークは自分で選択する
    • testacularという名前から最近変わった
    • 変更監視によるテストの自動実行
• 番外編
  • Capybara-webkit＋Cucumber
    • 受け入れテストを自動的に実行することが出来る
    • ユーザの操作をフィーチャーで記述して実行する
    • 詳しくは@ITの連載を覧てください。
• その他
  • Vows
  • Buster.js
• どうやって選ぶか？
  • どんなものをつくるつの？
  • なにでつくるの？
  • どうやってつくるの？
  • をまずは決めましょう
  • 自分たちの開発スタイルを決めよう
  • とは言え、迷う
    • なので、書いてて心地いいものを選べばいい

講演者による座談会

• テストをテスト未経験者に取り入れてもらうには
  • 佐伯さん
    • 自分の経験では、最初に訓練をうけたので、それが当たり前だと思っている
    • 開発標準を決めてしまう会社なので、盛り込んでしまえば良い
  • 斎藤さん
    • テストが楽しそうというところからはじまった
    • コードを書く上で大切なひとつのプロセスである
    • ペアプロでやっていくのがいいのかなぁ
    • 赤いものを緑にしたくなるゲーム性
    • 一緒にみていくのがいい
  • 佐藤さん
    • テストのスケルトンとか、生成するものを作ってくれた
    • 書き始めるまでが、よっこらしょだったのが、楽になった
    • とりあえず、コンストラクタまででいいから書けよがルール
  • 外村さん
    • ちょっとしたライブラリから始めたらいいのではないかな
    • いきなりアプリだと難しい
• テストを書いていてよかったと思ったエピソード
  • 斎藤さん
    • テストがある状態のコードがあれば、いきなりリファクタリング出来る
    • まず、綺麗にしてからコーディングすることが可能
  • 佐藤さん
    • コードの書出しが苦しむところ
    • まずテストを書いてしまえば、滑り出しがよくなる
    • コメントで書いていたことをテストに置き換えた
  • 佐伯さん
    • テスト無しでリファクタリングはありえない
    • 途中で任された場合
    • ちゃんとメンテナンスされていれば、そこから仕様を読み取れるので良いですよね
  • 外村さん
    • 1年前に書いたコードをメンテナンスすることになった時に良かったと感じました
• システムの規模は
  • 佐伯さん
    • 逆に聞きたいです
  • 斎藤さん
    • プロジェクトのしごとをあんまりしていないので、あんまりわかんないです
    • 100％書きたいですが、一旦メインで30％書いて、あとはドキュメンテーション
  • 佐藤さん
    • kintonを作っています、3年以上開発
    • JavaScriptだけで17万行あります
    • フレームワークにClosureライブラリを使っているので、冗長感はあります
    • テストコードは2万行強、カバレッジは計測していない
    • 結合テストも合わせてやっていた。結合テスト偏重だった
    • だんだん立ち行かなくなったので、UTを今増やしているところ
    • カバレッジは？
    • 30%くらいですかね
• 結合テストはどこまでやっているか
  • 佐伯さん
    • やんなきゃいけない。Seleniumでやっている
    • Unitが足りてないので、片手落ち
  • 斎藤さん
    • Unitテストはやっているけど、結合テストはやっていないような状況
  • 佐藤さん
    • Seleniumはやっていると膨大な時間がかかってしまう
    • 受け入れテストレベルに限定すると、現実的な時間で終わるようになる
    • Seleniumは何を作るべきかを担保する
    • 中身については、Unitでやっていこうよ！となっています
    • Jenkinsで回しています
    • 対応ブラウザもろもろで
• UI（View）のテストをどこまでやっているか
  • 佐藤さん
    • Viewの部分はあんまり書いていない
    • Renderで要素が入った・・・くらいまでしかやっていない
    • Clousureライブラリだと、JavaScriptの型チェックが出来る
    • よってビューのテストは型チェックだけ通ればOKだとおもわれる
    • それ以上のロジックが書かれていないことが前提
  • 斎藤さん
    • ロジックの部分がほとんどです
    • Renderに入ったとこくらいです
  • 佐伯さん
    • やってないっす
    • 導入する時に、ここまでやればいいんだよ！って決めてしまえばいいだけです
    • むしろ、ちゃんとアーキテクチャを設計するのが先で、後は、努力目標とすればよいと思います
• TDD VS BDDについて
  • 外村さん
    • どっちでもいいと思います！
  • 佐藤さん
    • 違いが正直わかっていません
    • 書き方レベルで言うと、BDDの方が好きです
    • テスト名を文字列で定義出来るのがいいですね
    • 2重のフィードバック・ループを考えるとBDDになるのではないでしょうか。
  • 斎藤さん
    • 平和主義なので、どっちでもいいです
    • スタイルとしては、BDDの方が好みではあります
    • テストがあればいいよ
  • 佐伯さん
    • テストの見通しをもった上では、BDDの方がいいのかなとは思います
    • ペアプロでやるのでは、BDDの方がやりやすいかもしれないですね

QAタイム

• テスト結果の出力は？
  • 佐藤さん
    • テストはCIツール（Jenkins）でやっています。
    • リポジトリにコミットするごとに動きます。
    • それで、エラーがあれば通知しています。
• テストの工数はどうやってもらえますか？
  • 佐藤さん
    • 難しいので、誤解を恐れずに言えば、多めに工数を取ればよいです。
    • コードを品質を担保するためには、その工数を取ればいいです。やましいとかではないです。
    • 細かいこと言ってもしょうがないです。技術じゃない人に対して。
    • これを実装するなら、これくらいと言ってしまえば良いのでは。
  • 佐伯さん
    • お客さんに、最初に説明をしました。
    • その上で、納得して頂く。結構しっかりやっていたパターンです。
  • 外村さん
    • バグったらその分工数食うんだから、最初から取っておいてもいいのではないか

Googleのえーじさん

• 仕事を手伝ってください
• ブログに書いているので、見てみてくださいね。
• Google の Developer Advocate とはどんな仕事なのか？: Tender Surrender