上記のシナリオを実行した後、データベース内のPINにアクセスできるとします。その場合、PINが実際に生成されたことを確認して確認するシナリオにもう一度足を伸ばします。その時点で、PINをローカル変数に格納し、次のシナリオで使用することができます。
だからあなたの最初のシナリオは次のようになります。
Get generate PIN page
Enter user name
Enter password
Click on submit button
Confirm PIN number in database
最後のステップは、セレン以内に行うが、APIコールまたはデータベースからPINを取得するためのいくつかの他の手段を介してすることではないでしょう。 PIN(例えば、regex=/^\d{4}$/
)を確認し、@customer_pin
(Rubyを使用していると仮定)などのローカル変数に格納します。
あなたの次のシナリオでは、このような何かを始めるでしょう:
Get generate login page
Enter customer ID
Enter customer PIN
etc
あなたがヒットすると、「顧客のPINを入力します」ステップは、あなたがローカルに格納されている変数(@customer_pin
)からそれを引き出します。
この2番目のシナリオを実行すると、このシナリオを順不同で実行する必要がある場合に備えて、ローカルに保存された変数内に正当なPINがあることを確認することができます。私は、変数をグローバルにアクセスできるようにするために$customer_pin
代わりの@customer_pin
を使用し、この場合、
Before do
$dunit ||= false
return if $dunit
$customer_pin = nil
$dunit = true
end
:あなたはグローバル変数を使用して、このようなあなたのfeatures/support/env.rb
ファイル内の「前」フックを実行することによってこれを行うことができます。その後、最初のシナリオを実行した後、$customer_pin
は正当な値に割り当てられ、後続のシナリオで使用できるようになります。後続のシナリオでは正規表現を使用して正当な値を持つことを確認し、そうでない場合は例外を発生させます。
提案は、シナリオの実行順序とシナリオの成功に基づいています。私は実行命令を前提とし、他のシナリオからの成功を期待することに対してアドバイスをします。それはよく知られている反パターンです。 –
一般に私は同意しますが、人生のほとんどのもののように...それは依存します。上記のケースは、プログラミングパターンを破るための良い言い訳の悪い例かもしれないので、あなたの心配はよく受けられます。しかし、時には私は大きな財産の精神でパターンを破ることがあります。たとえば、より大きなテストのための足踏みとして小さなテストを実行することは、すべてのテストのバックグラウンドセットアップを繰り返すよりも、より便宜的で侵襲的ではありません。 –