※2016/6/20 追記
この記事は検証が不十分な点が多々あったので参考程度に見てください。

ヾ(・ω<)ﾉ"　三三三●　ⅱⅲ コロコロ♪

------------------- ↓ 余談はここから ↓-------------------

behat3を実運用すると待ち時間と同様に困ることが一つある。
それは

ログイン継続

behat3の仕組みでは１つのシナリオごとに１セッションという扱いになっていて、
シナリオを跨ぐとCookieはリセットされている。
(たぶんbehat2も)

例えば会員向けサイトがあったとして、
シナリオアウトラインを使って会員専用ページのテストをしようとすると、
テスト一つ一つに必ずログイン認証のフローが必要になる。
テストファーストを念頭にやっているととてもじゃないがテストの時間がかかりすぎてしまう。

そこでセッションを継続できないか調査してみたのだが、
異常なまでに難しくて何度か断念した。
（cookieファイルを丸ごと入れ替えまでやったが駄目だった。。。）

o(￣ー￣；)ゞううむ無理かな。。。

ある日、とあるパッケージ(後日記事にすると思うが)を触っていると、
何気にセッションが継続されていることに気が付いた。
理由を調べてみると意外にも簡単な方法だった。
なので、今回はそれを紹介してみる。

------------------- ↑ 余談はここまで ↑-------------------

ヾ(・ω<)ﾉ"　三三三●　ⅱⅲ コロコロ♪

------------------- ↓ 本題はここから ↓-------------------

ログインセッション継続

FeatureContextに以下の内容を記述。

FeatureContext.php

  /**
   * @AfterScenario
   */
  public function closeBrowser()
  {
    $this->getSession()->stop();
  }

これだけ。

------------------- ↑ 本題はここまで ↑-------------------

ヾ(・ω<)ﾉ"　三三三●　ⅱⅲ コロコロ♪

------------------- ↓ 補足はここから ↓-------------------

では解説。
一つのシナリオの開始から終了までのライフサイクルを書いてみると、

といった具合。
シナリオを始める前にCookieの初期化が行われ、
この時点でセッションが継続できなくなるわけだ。

だが、一つだけポイントがある。
削除されるCookieは

”現在動いている”セッション

に限ったものになる。
つまり停止しているセッションは対象外となるわけだ。
ならばシナリオが開始される前、つまり前回のシナリオが終わった時点でセッションを停止すればいい。

ログインがいちいち切れてお困りの方は試してみるといいだろう。

behat 3.0 でBDD:ログインセッション継続