Download to read offline
![DB技術[実践]入門を読んだ](https://cdn.slidesharecdn.com/ss_thumbnails/mysqlcasual-130224090642-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Casper導入資料
- 1.
- 2. Agenda ● テストとは ● E2Eテストの概要 ●Phantom + Casperについて ● 今後の課題とかやること
- 3.
- 5. テスト ● コンピュータのプログラムを実行し、正しく動作するか どうか確認する作業のこと ○ コードを書く→保存する→ブラウザで確認 ○予めテスト項目を書いておいて自動で走らせて確認 ● プログラム(の挙動)を保護する ● 自動でやりたい ● どんなテストがあるのか ○ 単体テスト:メソッド、クラス単位。モデルのテストに相当 ○ 結合テスト:複数のクラスをテスト。コントローラに相当 ○ E2Eテスト:システム単位のテスト。今回の目的。
- 6. 自動でテストすると何が良いのか ● 網羅的で高速なチェックが可能 ● コードを変えても機能が変わらないことを保証 ●挙動を変わった原因を容易に把握できる ○ すぐ治せる ● リファクタリングに先立って必要
- 7.
- 8. End-2-End(E2E)テストとは ● システムを外側から見たテスト ● 受け入れテストが日本での正式名称 ●今回で言うと、 ○ ある値をpostした時に ○ 期待するHTML(あるいは文字列)が返ってくるか ● 内部の実装に依存せず書ける
- 9.
- 10. Phantom.JSとは ● ブラウザ ● GUIを持たない(ヘッドレス) ●JavaScriptで操作を記述する ● Ajaxリクエストの改変、監視なども行える ● これだけでも受け入れテストが書ける →しかしcookie周りとかの記述がとても大変 簡単な操作でも、細かいとこまで記述 →管理できずに破綻する未来が見える ● そこでCasper.JS
- 11. Casper.JSとは ● phantomの操作を簡単に行うためのライブラリ ● CoffeeScriptも使用可能 →記述量の削減 ●便利メソッド(操作、テスト)がたくさん ● Phantomのみにしか依存しない →Phantom使えるならCasperをcloneするだけ ○ 開発者が気軽に実行できないと続かない ○ 競合ライブラリは重くてでっかい何かに依存している
- 12.
- 13.
- 14. 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
- 15.
- 16. 運用時のディレクトリ構成 $ 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
- 17. 運用にあたっての懸念(課題) ● 変数が直書き ● 原因不明な失敗がある... ○操作の間で適切にcasper.then()を入れるべき？ ● 継続的にE2Eテストをメンテするモチベーション ○ Jenkins? ○ エクセル管理? ○ テスト記述を推奨する制度、しくみ ● QAとの連携 ○ TestLink ○ QAチームのテストエンジニア化計画も... ● テスト実行に際する冪等性 ○ 毎回DBが膨らんでゆく...
- 18. 懸念を払拭する:テストケースの管理 ● 値を切り出す ○ 値(与える入力と期待する出力)とテストロジックの分離 ○テストロジックの重複を排除 ○ 値は分離して何かで管理 ● 各種管理ツールの導入 ○ えくせる的な何か ○ TestLink ○ Jenkins
- 19. やるべきこと ● 継続的にメンテできる体制の構築 ○ テストは常に網羅されている状態を維持したい ○コードは常にテストを通る状態を維持したい ● テストケースの管理方法の制定 ○ 誰がどのシナリオ・ケースを担当し、書いたか ○ 期待する値の粒度 ■ 細かすぎると、些細な変更でもテストに通らない ■ 大きすぎると、肝心なときにコケてくれない ○ assert値をstatic変数にして別ファイルにしてinclude ● コーディング規約の制定 ○ @(=this)使わないほうがいいのか？ ○ CoffeeScriptのベストプラクティス
- 20. E2Eが第一歩 ● 内部の実装に依存しないで動作を保証できる ○ “テストのためのリファクタ”が基本的に不要 ○テストの中では一番手をつけやすい ● これが無いと次のリファクタを始められない ○ きちんと動いていることをテストが保証 ○ 人が確認していたことを機械が自動で確認 ● ここでテストの習慣ができれば... ○ 今後結合テスト、単体テストの導入も楽 ○ やってることは大して変わらない(操作してassert)
- 21.