3

私はまだBDD サイクルのcucumberとの組み合わせを理解しようとしています。rspec

非常に単純なログイン システム用に次のシナリオを定義しました。

Feature: Log in

In order to get access to the application
As a user
I want to log in

Scenario: User logs in successfully
  Given I exist as a user
  When I go to the login page
  And I fill in "username" with "gabrielhilal"
  And I fill in "password" with "secret"
  And I press "Login"
  Then I should see "Welcome gabrielhilal"
  And I should be redirected to the home page


Scenario: User enters wrong email/password combination
  Given I exist as a user
  When I go to the login page
  And I fill in "username" with "gabrielhilal"
  And I fill in "password" with "wrongpassword"
  And I press "Login"
  Then I should see "Invalid username/password combination."
  And I should see the login page again

steps次に、 に飛び込むのに適切な瞬間を待つことを定義し始めましたrspec。

ユーザーをシミュレートし、FactoryGirlステップを定義する最初のステップに合格しました。

Given(/^I exist as a user$/) do
  @user = FactoryGirl.create(:user)
end

セッションのルート、コントローラー、およびアクションを追加しました。

When(/^I go to the login page$/) do
  visit login_path
end

ログイン用のフォームを作成しました：

When(/^I fill in "([^"]*)" with "([^"]*)"$/) do |field, value|
  fill_in field, with: value
end
When(/^I press "([^"]*)"$/) do |button|
  click_on(button)
end

フラッシュ メッセージをレイアウトに追加しました。

When(/^I should see "([^"]*)"$/) do |arg|
  page.should have_content(arg)
end

ホームページ用のルートとコントローラー (static_pages) を追加しました。

When(/^I should be redirected to the home page$/) do
  visit home_path
end

最後のステップを解決しました：

When(/^I should see the login page again$/) do
  visit login_path
end

rspecそして、私はすべて緑色になりました...これらのシナリオでは、必要性を感じませんでした. 私は何が欠けていますか？

rspec で何をテストすべきかを理解しようとしています。rspecですべてをもう一度テストするのは正しくないと思います....

4

3 に答える 3

2

Cucumber/rspec 全体に関する私の経験は次のとおりです。最初に BDD と Cucumber を開始すると、例のようにすべてが緑色で問題ありません。その前にブラウザーを貼り付けて、実際のブラウザーでテストを行うこともできます。次に、Cucumber テストにさらに多くのものを追加し続けます。Web アプリケーションのスタック全体をテストしているため、(私にとっては) 大きなプラスです。ユーザーに表示される内容をテストしています。

しかし、テスト スイートが大きくなり、返されたページ内のタグのテストなどを開始すると、コードをリファクタリングするときに問題が発生し始めます。また、Cucumber は大規模なサイトでは遅いです。

私が最も効果的だと思うのは、Cucumer をできるだけ少なく、RSpec をできるだけ多く使用することです。テストを大幅に高速化します。したがって、コントローラーとモデルを RSpec でテストし、フロントエンドを Cucumber でテストするのが私の意見では正しい方法です (ほとんどの場合、フロントエンドのテストはあまりありません)。これらすべてが緊密に統合されていて、スタック全体をチェックしたい場合 (たとえば、ログインで行ったように)、Cucumber はこれらの状況に最適なツールだと思います。

于 2013-08-12T17:28:14.323 に答える
1

これまで rspec を使用する必要がなかった理由の 1 つは、コードが実際には機能を作成するのではなく、機能 (見た目からレールによって提供される) を「使用」しているだけだからです。これは、フレームワークを使用するときにかなり頻繁に発生します。

もう 1 つの理由は、きゅうりのシナリオが非常に低いレベルの抽象化で機能していることです。それらには、ログインの「方法」に関する詳細がたくさんあります。このレベルでのテストは、単体テストの領域と多少重複するため、rspec の必要性がまだ明らかでないことは理解できます。

より高いレベルの抽象化でシナリオを作成した場合、rspec がどこで機能するかがわかります。

ログインするために、私はハッピーパスのためにこのようなものを書きます

Given I am a user
When I login 
Then I should be logged in

そして、おそらく1つまたは2つの悲しいパスを書きます。

Given I am a user
When I login with a bad password
Then I should not be logged in

このレベルの抽象化で作業すると、シナリオがはるかに少なくなり (実行にかかる時間が短くなります)、詳細も大幅に少なくなります。これで、その詳細の一部を単体テストでカバーできるようになりました。たとえば、ビューで使用していたメソッド login_error_message がある場合、次のようなことを言うユニット テストを作成できます。

context 'bad password'
  login_error_message.should == 'bad password'
end

context 'bad login'
  login_error_message.should == 'login not found'
end

これを行うためにキュウリのシナリオを作成することもできますが、代わりに単体テストを使用する方がはるかに安価です (特にテストの実行時コスト)。

通常、Cucumber を使用して、ログインできるようにする必要がある「理由」とログインできることを文書化しますが、ログイン方法を指定する必要はありません。もちろん、これは非常にアートであり、特定のコンテキストに大きく依存し、さまざまな意見に対して非常にオープンです。しかし、キュウリを効果的に使用したい場合は、作成するシナリオごとに十分な効果を得る必要があります。

于 2015-01-03T08:18:13.623 に答える