仕様のリクエスト

テストは、デスクトップコンピュータ、モバイルデバイス、またはWebのアプリケーションであるかどうかにかかわらず、ソフトウェア開発の不可欠な部分になりました。 すでにこの段階の重要性と、この段階の不在がもたらす結果を誰も否定していません。 その中でも、各要素（ページ）をチェックするのに多くの時間を費やし、製品の動作に予期せぬ驚きをもたらし、プログラムを修正するコストが増加しました。 テストを記述する原則は非常に単純です-「黄色」、「赤」、「緑」、リファクタリング。 黄色は保留中のテスト、赤は失敗したテスト、緑は正常に機能しているシステムです。

プログラミングの種類ごとに、多くの種類のテストがあります。 しかし、どこにでもある共通点があります。 私の主な仕事はRORでWebアプリケーションを作成することなので、これらのアプリケーションをテストする機能について話しましょう。

環境設定

多くのテスト環境（Test Unit、Rspec、Cucumberなど）を見つけることができますが、私は個人的に積極的にRspecを使用しています。 これにより、テストの外観を美しくすることができますが、同時にコードの外観を維持することができます。 gemfileに、新しいグループを追加します。

group :development, :test do
gem "rspec-rails", ">= 2.5"
end

「なぜ開発モードにrspecを追加するのか？」と驚くかもしれませんが、すべてが非常に単純です。rspecは、モデル、コントローラー、scaffoldを生成するときに適切な仕様を追加します。 gemをインストールしたら、最後のインストールコマンドを実行しましょう。

rails g rspec:install

これで、rake rspecコマンドを使用してテストを実行できます。 このアプローチのマイナス面は、プロジェクトのわずかな変更でも、このコマンドを何度も実行する必要があり、絶対にすべてのテストが実行されることです。 したがって、代わりに必要なコマンドを実行するには、ウォッチャーを見つける必要があります。 現時点では、自動テストとガードという2つの優れたソリューションについて知っています。 Autotestは、他のフレームワークからレールに到達しました。 しかし、最近、私はガードの形で素敵なソリューションに会いました。 ガード自体には必要な機能はありませんが、アドオンで使用すると、非常に豪華なものになります。 警備員はこれらの追加の約2ダースを持っています、そして、彼らは巨大な機会を運びます。 ただし、1つだけ説明します。guard-rspecです。 必要なファイルをインストールします。

group :test do
gem 'guard-rspec'
end

初期化コマンドを実行します。

guard init .
guard init rspec

1つ目はガードファイル（オブザーバー設定ファイル）を作成し、2つ目はrspec固有のアクションを追加します。 これで、guardコマンドを使用して、必要な仕様を作成するためにいつでも準備ができているウォッチャーを使用できます。 しかし、このソリューションのログは非常に退屈なので、色を追加しましょう。 まず、通知ライブラリをインストールします。 そして、ここで最初の問題に直面しています-あなたとあなたのパートナーは異なるOS（Mac OSとLinux）を持っていますが、誰もがテストする必要があります。 私たちの解決策は次の解決策でした：

gem 'libnotify' , :require => false if RUBY_PLATFORM =~ /linux/i
gem 'rb-inotify', :require => false if RUBY_PLATFORM =~ /linux/i
gem 'rb-fsevent', :require => false if RUBY_PLATFORM =~ /darwin/i

次に、rspecのすべてのポイントをパーセンテージ計算で置き換えます。

gem 'fuubar'

最後に、Guardfileに以下を記述します。

guard 'rspec', :cli =>'--format Fuubar --color'

テストを実行します。 コンソールに美しいプログレスバーが表示され、テストが完了すると、ポップアップウィンドウが表示されます。

テスト環境をセットアップするための次のステップは、テストに純度を与えることです。 結局のところ、テストを実行するときに以前のチェックでデータベースの値やレコードに出くわすことを望んでいません。 この場合の適切な選択は、gem database_cleanerです。 その構成を以下に示します。

config.before(:suite) do
DatabaseCleaner.strategy = :truncation
end

config.before(:each) do
DatabaseCleaner.start
end

config.after(:each) do
DatabaseCleaner.clean
end

クリーナーをセットアップした後、テスト可能なコンテンツの作成について話すのは良いことです。 Rspecはモックの使用を推奨していますが、個人的には、実際のオブジェクトを生成することを好みます。 machinistまたはfactory_girlを使用して、さまざまなオブジェクトを作成できます。 私は機械工に特に詳しくないので、彼については何も言えません。 しかし、私は長い間factory_girlと仕事をしており、gemは苦情を申し立てたことはありません。 宝石をテストグループに追加します。

group :test do
gem 'guard_rspec'
gem 'factory_girl_rails'
gem 'database_cleaner'
end

リンクのこの記事以外で検討することを提案する残りの使用

テスト自体

基本的なテスト環境を確立したら、その機能について説明できます。 Rspecはすべてのテストを部分的に分割します。つまり、appセクションのフォルダーのコピーがspecフォルダーに作成されます。 控えめな開発およびテスト期間中、モデル、ヘルパー、メーラーセクションのみが有用であることがわかりました。 そして、「コントローラーとビューの最も重要なコンポーネントをどうするか」という疑問が生じます。私の意見では、rspecが提供するソリューションは完全ではなく、まったく現実的ではありません。 したがって、開発のために、要求をテストし、応答を受け取りました。 これを行うには、capybaraをインストールします。 ライブラリの作成者（Jonas Nicklas）は次のように説明しています。

「Capybaraは、Rails、Sinatra、MerbなどのRackアプリケーションの統合テストのプロセスを簡素化することを目指しています。 カピバラは、実際のユーザーがWebアプリケーションと対話することをシミュレートします。

文字通り次のように聞こえます：

「カピバラモルモットは、アプリケーションでのユーザーの行動をシミュレートすることにより、包括的なテストプロセスを簡素化します。」

gemfileに追加します。 その後、ファイルspec / test_helper.rbにCapybaraライブラリを追加する必要があります。

require 'capybara/rspec'

現在、私たちのテストは、多くの機能的で便利なテスト方法と仮想ページの操作で満たされています。 順番に始めましょう：

ページへの訪問は、訪問訪問メソッドを使用して行われます。

visit '/'

小文字のアドレスに加えて、このメソッドはRailsパスヘルパーを受け入れます。

visit car_wheels_path(car)

ただし、ライブラリの主な機能は、アクセス可能なページオブジェクトです。 このオブジェクトは、テスト用の仮想ページです。 その内容を取得するには、bodyメソッドを使用するだけです。

puts page.body

操作コマンドのリストを見てみましょう。 テキストとパスワードのフィールドはfill_inメソッドで埋められます。このメソッドはid、class、name要素を持つ最初のパラメーターを受け取り、withパラメーターでコンテンツを設定します。

fill_in 'car_manufacture', :with=>'Audi'
fill_in 'car[model]', :with=>'A4'

selectでオプションを選択するには、selectメソッドが使用されます（ありがとう、Kep）。最初に値を受け取り、次に操作用の要素を受け取ります。

「シルバー」を選択します：from => 'car [color]'

チェック、チェック解除、選択のメソッドもあり、その目的はチェックボックスとラジオボタンの状態を変更することです。 要素の識別子のみを受け入れます：

check 'car[full_package]'
choose 'car[year][2010]'

しかし、ページに同じ名前の要素がいくつかある、またはidが存在することがあります。 これを行うには、指定した要素内の検索を制限するブロック内メソッドがあります。

within 'form#payment_card' do
#
end

ボタンとリンクをクリックする方法はいくつかあります-ユニバーサル（click_on）と特定（click_link、click_button）：

click_on 'submit_form'
click_link 'read_more'

次に、結果の構造の確認に移りましょう。 DOM要素の存在を確認するために、have_selectorメソッドが存在します。

page.should have_selector('table tr')

しかし、これらの要素の数を確認する必要がある場合はどうでしょうか？ それは十分簡単です-countパラメーターを追加してください：

page.should have_selector('table tr', :count=>3)

要素自体がfazhnではなく、コンテンツのみが重要な状況では、page.have_contentメソッドが便利ですか？

page.should have_content(“Audi club”)

しかし、jsはどうですか？

いくつかの仕様を書いたので、あなたはすでにcapybaraがjsスクリプトを完全に無視していることに気付きました。 開発者は、テストに合格したときにパフォーマンスが維持されるため、この手順を実行しました。 すべての機能を備えたページを確認する必要がある場合は、js specパラメーターを使用します。

it 'should have many js', :js=>true do
visit …
end

お気に入りのブラウザのウィンドウが表示され、テスト済みのページが開き、カーソルがすべての動きをします。 ただ魔法ですが、それを理解しましょう。 実際、カピバラはテストページを処理するようにWebドライバーを切り替えました。 デフォルトでは、応答で受信したコンテンツでのみ動作するラックドライバーが使用されます。 jsパラメーターを使用すると、capybaraはセレンドライバーへのアクセスを開始します。 Seleniumは、特に指定されていない限り、システムブラウザーを起動し、必要なすべてのアクションを実行します。 いくつかの点を除いて、すべてが美しく美しくなっています。 まず、テストの実行時間が非常に長くなります。 そして、驚くことではありませんが、レール環境自体をロードすることに加えて、テストはブラウザーを起動し、さらに操作にも時間がかかります。 第二に、ブラウザが常に表示されることに不満でした。 したがって、代わりのWebドライバーであるcapybara-webkitを優先して、セレンを放棄する必要がありました。 このgemは、これらの問題を解決するために特別に作成されました。 ライブラリをインストールするには、capybara-webkit自体に加えて、別のqtライブラリをインストールする必要があります。 spec_helperの後、javascriptを使用するページに使用するドライバーを指定します。

Capybara.javascript_driver :webkit

これで、カピバラは統合テストを不要なアニメーションなしで迅速に実行します。

もう1つの興味深い点は、ajaxを使用して読み込まれた要素をチェックすることです。 have_selectorメソッドとhave_contentメソッドは常にパスするとは限らないため、最初にall、find、などのメソッドを使用します。

first('div.info').should be

all('tr.ads').should have(3).items

また、findおよびfirstメソッドは、ボタンおよびリンク以外の要素のクリックをエミュレートするのに役立ちます。

first('div.catalog').click
find('p#info).click

スクリプトを実行したい場合は、カピバラがここで役立ちます。

page.execute_javascript “alert('Hello world')”

最初は、これは完全なナンセンスのように見えます-「じゃあ、jsテストで実行するポイントは何ですか？」そして答えは、クリックして選択する以外のアクションにページの動作をトレースする必要がある状況です：

page.execute_javascript '$(“p.long_text”).hover();'

これが、カーソルの段落上でのホバーをエミュレートする方法です。

人生からのいくつかの観察

そして、私の投稿の最後に、個人的な経験からのいくつかのヒントがあります。 js Webドライバーでcapybara、database_cleaner、factory_girlを使用する場合、作成されたリソースはテストページに表示されません。 この状況を修正するには、次の設定：

config.use_transactional_fixtures = false

別の興味深いトリックは、rspecに焦点を当てることです。要求の厳しいテストでは、その有効性は否定できません。 フォーカス調整は次のとおりです。 まず、テスト環境の構成ファイルに次の行を追加します。

config.filter_run :focus=>true
config.run_all_when_everything_filtered = true

その後、目的のアクションを実行するには、名前パラメーターを追加するだけで十分です。focus=> trueで、仕様のリストがフィルターされます。

便利なリンク

カピバラ
カピバラウェブキット
データベースクリーナー
工場ガールレール
ガード