振る舞い駆動開発(BDD)はビジネス関係者とソフトウェア開発者の間のコミュニケーション改善に有効だが，Aslak Hellesøy(Cucumberの共同リーダ)，Matt Wynne，Steve Tooke各氏が先日の議論で説明したようなCucumberを使った自動テストを実行する場合には，いくつかのアンチパターンが存在する - Kevin Smith氏は先頃，このような主張をした。
Cucumberアンチパターンの多くは，機能レベルでの振る舞いを記述したシナリオに関するものだ。シナリオでは一般的に，何をすべきかを記述するために，そのドメインの言語を使って宣言的に表現する必要がある。構造としては，まず初期状態から始まり，シナリオを起動するイベントに続いて，最後に期待される成果を１つ以上の句として記述するという，Given-When-Then{/0]フォーマットが一般的なテンプレートだ。
Scenario: 銀行口座からの引き出しの正常な実施
Given 口座残高が100ユーロ
When 20ユーロを要求
Then 20ユーロ払い戻し
コード作成後にシナリオを記述するというのは，Cucumberをテストツールとして扱っていることになる。そのような方法も可能ではあるが，問題のドメインに対する理解の確認と，専門家を交えた潜在的な誤解の検出のためのツールとして，コード記述に先立って使用するのが本来の姿だ。
専門家が単独でシナリオを作成するのでは，共通的な理解を表現することはできないし，開発者やテスタからの貴重なインプットを見逃すことにもなる。技術的なインプットを欠くシナリオには，自動化が困難になる傾向がある。
UIを使用するテストは問題となる場合がある。ユーザインターフェースはビジネスロジックよりも変更がはるかに容易であるため，テストのフェールが発生しやすいのだ。シナリオとビジネスロジックが変更されていないのならば，テストの修復は無駄な作業ということになる。またUIテストでは，データストレージにアクセスしてデータを取得するなど，アプリケーションの全部分とのインタラクションが必要であるため，時間も非常に必要とする。このようなテスト方法は，ドメインに対する理解不足につながる可能性もある。さらにUIの使用方法は，多くのドメインに共通する汎用的な言語を中心に記述されるため，本来記述すべきドメインを反映した記述のされていないシナリオになりやすいのだ。
BDDの実践経験の豊富なスウェーデンのThomas Sundberg氏は，アジャイルテストのピラミッドを引用しながら，ビジネスが振る舞いに対して意見を持つべき理由のあるすべての場所で，BDDが使用されるべきだと主張する。氏はインテグレーションテストでのBDDの使用を重視し，UIの経由を可能な限り避けるようにしている。氏が強調するのは，Cucumberはテストツールが主なのではなく，システムの動作すべき方法の共通理解を捉えるためのツールである，という点だ。
空の銀行口座のチェックなどのノイズが多いシナリオは，ドキュメントの関連部分を分かりにくくする場合がある。それらは明白ではあるが，最初のイテレーションの実行では必要だ。Hellesøy氏らはこれについて，しばらく実行した後にこれらのシナリオを削除するか，少なくともより有用な内容に書き換えるようにアドバイスする。
シナリオの過度な利用はテストを遅くする。 シナリオのアウトラインを導入し，テンプレートを使って新たなシナリオを追加することで，多数のシナリオを容易に追加することができるようになる。アウトラインを使用する場合は，実行に時間を要するUIなどを通じたテストは避けた方がよいだろう。
その他に議論されているアンチパターンとしては，ルールの多いテスト，不適切なシナリオ名称などがある。いずれもシナリオの目的に対する誤解につながるものだ。本質を外した内容や漠然としたシナリオでは，無関係な内容があまりに多過ぎる，あるいは詳細を含まず抽象的に終始するなどの理由のから，何の価値も加えることはできない。
この記事を評価
- 編集者評
- 編集長アクション