Casper導入資料

6,769 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,769
On SlideShare
0
From Embeds
0
Number of Embeds
4,747
Actions
Shares
0
Downloads
5
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Casper導入資料

  1. 1. Casper.JS導入資料 @saisa6153 2013/9/12
  2. 2. Agenda ● テストとは ● E2Eテストの概要 ● Phantom + Casperについて ● 今後の課題とかやること
  3. 3. テストとは
  4. 4. テスト ● コンピュータのプログラムを実行し、正しく動作するか どうか確認する作業のこと ○ コードを書く→保存する→ブラウザで確認 ○ 予めテスト項目を書いておいて自動で走らせて確認 ● プログラム(の挙動)を保護する ● 自動でやりたい ● どんなテストがあるのか ○ 単体テスト:メソッド、クラス単位。モデルのテストに相当 ○ 結合テスト:複数のクラスをテスト。コントローラに相当 ○ E2Eテスト:システム単位のテスト。今回の目的。
  5. 5. 自動でテストすると何が良いのか ● 網羅的で高速なチェックが可能 ● コードを変えても機能が変わらないことを保証 ● 挙動を変わった原因を容易に把握できる ○ すぐ治せる ● リファクタリングに先立って必要
  6. 6. E2Eテストの概要
  7. 7. End-2-End(E2E)テストとは ● システムを外側から見たテスト ● 受け入れテストが日本での正式名称 ● 今回で言うと、 ○ ある値をpostした時に ○ 期待するHTML(あるいは文字列)が返ってくるか ● 内部の実装に依存せず書ける
  8. 8. Phantom+Casper
  9. 9. Phantom.JSとは ● ブラウザ ● GUIを持たない(ヘッドレス) ● JavaScriptで操作を記述する ● Ajaxリクエストの改変、監視なども行える ● これだけでも受け入れテストが書ける →しかしcookie周りとかの記述がとても大変  簡単な操作でも、細かいとこまで記述  →管理できずに破綻する未来が見える ● そこでCasper.JS
  10. 10. Casper.JSとは ● phantomの操作を簡単に行うためのライブラリ ● CoffeeScriptも使用可能 →記述量の削減 ● 便利メソッド(操作、テスト)がたくさん ● Phantomのみにしか依存しない →Phantom使えるならCasperをcloneするだけ ○ 開発者が気軽に実行できないと続かない ○ 競合ライブラリは重くてでっかい何かに依存している
  11. 11. E2EテストBeforeAfter 操作を記述 駆動 リクエスト レスポンス レンダリング 出力 リクエスト レスポンス ブラウザを直接操作 変更項目を目視確認 アプリケーション アプリケーション ブラウザ
  12. 12. 環境を作る
  13. 13. PhantomとCasperを準備 $ wget https://phantomjs.googlecode.com/files/phantomjs-1.9.2-linux-x86_64. tar.bz2 $ tar jxf phantomjs-1.9.2-linux-x86_64.tar.bz2 $ sudo cp phantomjs-1.9.2/bin/phantomjs /usr/local/bin/ $ git clone git://github.com/n1k0/casperjs.git $ sudo ln -sf `pwd`/bin/casperjs /usr/local/bin/casperjs
  14. 14. 今後やることなど テスト運用の話も
  15. 15. 運用時のディレクトリ構成 $ pwd ~/app $ tree ./test test ├── common │ ├── casper_inc.coffee │ └── casper_pre.coffee └── suite └── 01-trialA ├── 01-trialA.coffee ├── 02-trialA.coffee ├── 03-trialA.coffee ├── 04-trialA.coffee └── 05-trialA.coffee
  16. 16. 運用にあたっての懸念(課題) ● 変数が直書き ● 原因不明な失敗がある... ○ 操作の間で適切にcasper.then()を入れるべき? ● 継続的にE2Eテストをメンテするモチベーション ○ Jenkins? ○ エクセル管理? ○ テスト記述を推奨する制度、しくみ ● QAとの連携 ○ TestLink ○ QAチームのテストエンジニア化計画も... ● テスト実行に際する冪等性 ○ 毎回DBが膨らんでゆく...
  17. 17. 懸念を払拭する:テストケースの管理 ● 値を切り出す ○ 値(与える入力と期待する出力)とテストロジックの分離 ○ テストロジックの重複を排除 ○ 値は分離して何かで管理 ● 各種管理ツールの導入 ○ えくせる的な何か ○ TestLink ○ Jenkins
  18. 18. やるべきこと ● 継続的にメンテできる体制の構築 ○ テストは常に網羅されている状態を維持したい ○ コードは常にテストを通る状態を維持したい ● テストケースの管理方法の制定 ○ 誰がどのシナリオ・ケースを担当し、書いたか ○ 期待する値の粒度 ■ 細かすぎると、些細な変更でもテストに通らない ■ 大きすぎると、肝心なときにコケてくれない ○ assert値をstatic変数にして別ファイルにしてinclude ● コーディング規約の制定 ○ @(=this)使わないほうがいいのか? ○ CoffeeScriptのベストプラクティス
  19. 19. E2Eが第一歩 ● 内部の実装に依存しないで動作を保証できる ○ “テストのためのリファクタ”が基本的に不要 ○ テストの中では一番手をつけやすい ● これが無いと次のリファクタを始められない ○ きちんと動いていることをテストが保証 ○ 人が確認していたことを機械が自動で確認 ● ここでテストの習慣ができれば... ○ 今後結合テスト、単体テストの導入も楽 ○ やってることは大して変わらない(操作してassert)
  20. 20. がんばりましょう!!! 千里の道も一歩から

×