Download as PDF, PPTX
Uploaded byTakaaki Kasai
開発者による現実的な自動化テスト及びRubyのテストツールについて
社内勉強会で使った資料。開発者自身が行う自動化テストについての考え方と、実際に使っているテストツール(Cucumber, Capybara, PhantomJS等)について解説しました。 前半は開発者自身が書く自動化テストコードについての考え方、後半は具体的なテストコードの例を紹介しました。 前半については、テストの話題で一般的に言われている常識に真っ向から反抗しております。「カバレッジは気にしない」「単体テストより統合テスト優先」「テストファースト無視」など、一般的な常識からすると無茶苦茶なことを言っているようですが、リアルな開発の現場で、テストを有効に行うための現実論を述べています。 また、後半ではRubyを使ったテスト環境としてCucumber+Capybara+Poltergeist+PhantomJSの組み合わせを紹介し、Test::Unit, Rspec, Cucumberで同じテストを行う時のコードの違いや、Cucumber+Capybaraの組み合わせを使う際の柔軟性のあるステップ定義などを述べました。 なお、今回のスライドで使用したデモのソースコードはGitHubにアップしています。ご自由に活用ください。 https://github.com/takaaki-kasai/cucumber-demo/tree/master
More Related Content
開発者による現実的な自動化テスト及びRubyのテストツールについて
- 1.
- 2.
- 3.
- 4. なぜテストの自動化が必要なのか • ここでいうテストとは開発者が自ら書くテストコードのこと • リグレッションテストの労力と時間を大幅に削減できる •以前書いたコードを壊していないことが保証できる （少なくともテストコードの仕様上は） • 開発者自身の心の安寧が得られる ← 重要 （余計なことを考えず今眼の前にあるコードに集中できる） • リファクタリングが躊躇なくできる （壊したらどうしよう・・・なんて心配が不要になる）
- 5. そもそも「テストコードを書く」文化がない場合は？ • 「勝手にやりましょう」 • 人間、目の前で見せられるまで納得しない →いきなり「テストを書く時間をとらせてくれ」よりも 勝手にやってしまって、効果を見せた方が話が早い やっちまえ！
- 6. テストを書くのは品質の保証のため？ • 開発者自身が品質保証のためにやるのは大変 • あくまで 「リグレッションテストの手間と時間の削減」 「開発者の精神的安定と効率と集中力向上」 「リファクタリングによるコードの洗練」 のためにやるという考え方← 今回の話はこれ • 完全なテストはいらない → 過去のコードを壊していないか確認できればいい テストは過去のコードをチェックする センサーみたいなもの
- 7.
- 8. 単体テストより統合テスト • テストを書く目的が過去のコードを壊していないかの確認な ので、統合テストだけでも目的は果たせる • もちろん単体テストはないよりあったほうがいい。書く時間 があれば。 •時間が足りない時は、とりあえず先に実装を終わらせて後か ら統合テストだけ書く 「時間は作るもの」 なんて言うけど限界ある
- 9. TDDじゃないの？ • テスト駆動は確かに「理想」 → だけど、いちいちやってる時間あるか？ •全てをテストファーストにするのはあきらめる → 正直、UIまで含めてテストファーストはキツイ → そこまで秀才じゃないッス • 「雪だるま式」という考え方もある → 雪だるまは、最初に「核」になる部分を こねくり回して作って、それから転がして大きくする。 同じように、最初はテストを書かずに「核」を作って、 それからテスト駆動のサイクルを回す。
- 10.
- 11. 現在の自動テスト環境 • Cucumber • Capybara •Poltergeist • PhantomJS どういうこと？ Poltergeist
- 12.
- 13. Cucumberって？ • テストコード記述ツールの進化 Test::Unit →RSpec → Cucumber • Test::Unit Rubyのソースコードそのもの • RSpec ソースコードに自然言語による説明がつけられる • Cucumber 自然言語によるテスト仕様記述とソースコードを分離
- 14. サンプルアプリケーション Hello! ボタンを押すと Hello,World!! と表示するだけ test_rack_app.rb config.ru 実行コマンド $ rackup -o 0.0.0.0
- 15. Test::Unit • Rubyのソースコードそのもの • メソッド定義がテストの単位（先頭にtest_ をつける） • アサーション用のメソッドが用意されている（assert_*）
- 16.
- 17.
- 18.
- 19. • ソースコードに自然言語による説明がつけられる • ブロックでテストの単位を表す •より柔軟なアサーション: expect(*).to ∼ RSpec
- 20.
- 21.
- 22.
- 23. • 自然言語によるテスト仕様記述とソースコードを分離 • featureファイル:テスト仕様記述 → gherkin(ガーキン)という言語、ほぼ自然言語で書ける • step定義ファイル: ソースコード → featureをrubyのコードに翻訳 Cucumber
- 24.
- 25.
- 26.
- 27.
- 28. テストコードをもっと便利に • Webアプリケーションでよく使う動作や確認 例えば・・・・ ・フォーム内要素への入力 ・HTMLの特定のタグ内に文字列があることを確認 ・ボタンをクリック → 楽にテストを記述したい！ •そこで、Capybara Webアプリのテスト向けDSLが っている CSSセレクタやXPathが使える HTMLの特定要素の属性やテキストの比較がラクにできる
- 29.
- 30. Capybara+Cucumber（実行例: 失敗時） CSSセレクタで比較の範囲を絞ったので、エラーが分かりやすくなった → もちろん、自力でHTMLを解析して比較すれば同様のことは できるけど、しんどい。Capybaraを使えばラク。
- 31.
- 32.
- 33. さらにJavascirptもテストしたい • 統合テストであるからには、JSも含んだ動作を検証したい → JSのみの単体テストじゃなくて、ページ遷移なども 含めて自動でテストしたい • Seleniumって選択肢もあるけど、重い・扱いにくい • そこで「ヘッドレスブラウザ」を使う → 最近よく使われるのが PhantomJS 「コマンド一発打って待ってれば 全部完了」が理想ですね
- 34. ヘッドレスブラウザ PhantomJS • 中身はWebKit 正確にはQtWebKit • 公式サイトにあるビルド済みバイナリを使うのが吉 → 自力でビルとすると30分以上かかる可能性大 → 2ヶ月程前にメジャーバージョンアップ(2.0)したが、 2.0のビルド済みバイナリは未提供(2015.03.12現在) → なので、バージョン1系列の過去のバイナリを使う https://code.google.com/p/phantomjs/downloads/list • たまにクラッシュします（笑）さすがにWebKitを完全に動かすのは簡単じゃないっぽい 落ちた部分だけ再度テストを実行しましょう。
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.