4

私は Ruby コマンドライン プログラムを作成しており、Cucumber と Aruba を使用してテストしています。.featureAruba には非常に便利なマッチャーが含まれているため、ファイル内の数行で出力をテストできます。

When I run `myprogram`
Then it should pass with:
  """
  my program output
  """

問題は、私のプログラムには数十行、場合によっては数百行の出力が含まれている可能性があることです。それらすべてを.featureファイルに入れると、読み取りやナビゲートが難しくなります（そして、ちょっと不快です）。このような場合に出力をテストするための推奨される方法は何ですか?

4

4 に答える 4

7

簡単な答えは、そうすべきではないということです。

きゅうりのテストは、ユーザー向けで読みやすいものになっています。それらは機能を説明します。エラー出力がバイトごとに既知の値のバイトと一致するかどうかは、ユーザーは気にしません。

あなたは自分自身に尋ねる必要があります：私は何をテストしていますか？答えはエラーメッセージですか？おそらくそうではありません。アプリケーションのいくつかの機能をテストしています。本当に失敗することを確認したいのであれば、Cucumberシナリオで必要なのは次の行です。

Then the exit status should not be 0

これは、スクリプトがゼロ以外の終了ステータスがエラーを通知するという標準の規則に従っていることを前提としています。

シナリオで出力に特定のメッセージを含める必要がある場合は、次のメッセージを追加できます。

Then it should fail with
"""
Some error message
"""

ただし、これは出力全体である必要はなく、部分的に一致するだけです。（arubaには「正確に失敗するはずです：」と定義されていることに注意してください。ただし、これを使用することはお勧めしません。）

編集：あなたはあなたの例を失敗ではなく合格をテストするように変更しましたが、私の基本的なアドバイスは同じです：

  1. 出力の詳細をシナリオのロジックから分離します。コメントの例を使用して、ユーザーが生成した単一のコメントを出力できることを確認するテストと、正しい100個のコメントを出力したことを確認する別のテストがある場合は、100個である必要はありません。キュウリのシナリオでのコメントの価値のある出力。
  2. ユーザーの視点からキュウリのシナリオを作成してください。各シナリオでは、ユーザーにとって重要な何かをテストする必要があります。ユーザーが気にしないときに実装から漏れるものをすべて削除して、それらを最小限に抑えるようにしてください。
  3. これを実現するには、部分一致をテストする組み込みのArubaコンストラクトを使用します。出力でキーワードまたはフレーズを探します。Cucumberテストは読みやすくなるだけでなく、より堅牢になり、関連のない出力変更の影響を受けなくなります。
于 2012-12-11T23:20:20.297 に答える
2

プログラムをテストするには、次の 2 つのオプションがあります。

  1. メッセージの関連部分 (このテストで実際に確認したいこと) のみを確認します。Aruba には組み込みの stepdefがあるため、非常に簡単です。

  2. 完全なメッセージを確認してください。メッセージが短い場合は、Aruba の組み込みの stepdefを使用できます。ただし、メッセージが長い場合は、別のファイルに入れることをお勧めします。Aruba にはそのようなメソッドが含まれていないため、この stepdef を自分で作成する必要があります。

次のようになります。

# Require aruba/api before that
Then /^it should (pass|fail) with message from file "(.*)"$/ do |pass_fail, filename|
  exact_output = File.read(filename)
  Aruba::API::assert_exit_status_and_output(pass_fail == "pass", exact_output, true)
end

たくさんのテストを書きたいと思っていて、たくさんのメッセージが似ている場合、たくさんのWETメッセージになってしまうかもしれません。完全なメッセージをアサートすると、変更があった場合にテストのサポートが難しくなります。

したがって、ある種のテンプレート エンジンを使用してこれらのメッセージをアサートし、テストを DRYer にすることができます。

テストを別の方法で設計できます。
最初の方法のみを使用すると、すべてをテストするわけではないため、テストで回帰バグが検出されない場合があります。2 番目の方法を使用する場合、メッセージ間の繰り返しが多い場合、サポートが非常に難しくなる可能性があります。

したがって、これら 2 つのオプションの間にはトレードオフがあります。通常、方法 1 でいくつかのテストを作成し、方法 2 で別のテストを作成します。私は黄金律を知りません。

于 2012-12-11T22:09:05.960 に答える
0

私は次のことをお勧めします：

When I run `my_app`
Then the exit status should not be 0
And the output should contain:
"""
some output
"""

このように、「一部の出力」がプログラムから出力される限り、テストは合格しますが、追加の出力は無視され、テストはそのすべての出力を持つ必要はありません。

これらすべてを1つのステップで主張したい場合は、自分で作成してください。ただし、これはより明確だと思います。

于 2012-12-15T14:49:36.730 に答える
0

アプリで何百もの出力があっても驚くことではありません。はい、読みやすくする必要があります。Cucumber 機能ファイル内でそれを行うことができない場合は、置換するより良い場所がないと思います。結局のところ、Cucumber はすべて平易な英語であり、ライブ ドキュメントとして機能します。

必要なのはそれらを整理することだけです。あなたがそれらを無視した場合に備えて、ここにいくつかの基本的なヒントがあります.

  1. .featureファイルごとに 1 つのトピックのみをカバーする特定の機能を記述します。When I run my programあなたの言及がデモ目的であることは知っていますが、そのような広範なトピックは受け入れられません.

  2. .featureファイルをfeatures/フォルダーに入れます。そして、必要に応じて、さらに のようなサブ フォルダーに分割しますfeatures/user/user_login.feature。

  3. Scenario Outlineおよびを使用しExamplesて、1 つのシナリオで同様の出力を整理します。例には、それぞれを明確に表す行があります。

これらが役立つことを願っています。

于 2012-12-11T05:54:51.023 に答える