4

私には同じシナリオがたくさんありますが、それらは渡されるデータによってのみ異なります。これは例です：

機能：レポートからExcelドキュメント
へのファクトのリンクファクトをExcelドキュメントにリンクするため
にレポートにアクセスできるユーザーとして、
レポート内のファクトの値をクリックしたい

シナリオ：
管理者として管理者としてログに記録され、
サンプルプロジェクト
を選択し、factcollection1とすべての期間およびすべてのクライアントからのデータを含むレポートプレゼンテーションビューを表示することを選択した場合、任意のURIアイテム
ExcelセルC2
をクリックし、任意のURIアイテムというタイトルの行の2列の値次に、
ExcelセルC2にインターネットアドレスの値が含まれている必要があります

シナリオ：Base64バイナリアイテム
管理者として管理者としてログに記録され、
サンプルプロジェクト
を選択し、factcollection1とすべての期間およびすべてのクライアントからのデータを含むレポートプレゼンテーションビューを表示することを選択しました。Excel
セルF3
をクリックして、 base64バイナリアイテムというタイトルの行の2列の値次に、
ExcelセルF3に値asdfが含まれている必要があります

シナリオ：ブール項目
管理者として管理者としてログに記録され、
サンプルプロジェクト
を選択し、factcollection1とすべての期間およびすべてのクライアントからのデータを含むレポートプレゼンテーションビューを表示することを選択しました。Excel
セルJ3
をクリックして、値をクリックします。 boolean itemというタイトルの行の2列に、
ExcelセルJ3に値trueが含まれている必要があります

これを短くして、次のようにします。

シナリオの前：
管理者として管理者としてログに記録され、
サンプルプロジェクト
を選択し、factcollection1とすべての期間およびすべてのクライアントからのデータを含むレポートプレゼンテーションビューを表示することを選択した場合

シナリオ：
ExcelセルXX
をクリックし、ZZというタイトルの行のYY列の値をクリックすると、
ExcelセルYYに値WWが含まれるはずです。

そして、次のようないくつかのテーブルデータよりも：

| XX | YY |          ZZ        |              WW              |
| C2 | 2  | any uri item       |    some internet address     |
| F3 | 2  | base64 binary item |               asdf           |
| J3 | 2  | boolean item       |        true                  |

私は解決策を見つけました。

この機能を備えたシナリオの概要があります。

Scenario Outline: display label in selected language
Given I am logged as <username> with <password>
  And I have clicked on <button> button
  Then result should be some result

Examples:
  | username | password | button |
  |  john    |  doe     | first  |
      |  foo     |  bar     | second |
4

3 に答える 3

3

You could use Scenario Outline instead of Scenario. Your example would look something like this:

Scenario Outline: 
  Given I am logged as admin with admin
  And I have selected Sample Project
  And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients
  When I click on excel cell '<Cell>'
  And I click on the value in '<Column>' column of the row entitled '<Row>'
  Then Excel cell '<Cell>' should contain value '<CellValue>'

Examples: 
  | Cell | Column | Row                | CellValue             |
  | C2   | 2      | any uri item       | some internet address |
  | F3   | 2      | base64 binary item | asdf                  |
  | J3   | 2      | boolean item       | true                  |
于 2011-11-22T00:53:36.590 に答える
1

This is a very interesting question and I have spent some time researching what I call "data driven Specifications". This is partly inspired by the "row-test" or "data-driven-test" features that many common test frameworks offer.

Not that I use the terms "Scenario" and "Specification" synonmous, however I prefer the latter.

Similar to a normal unit test, a BDD specification is composed of three parts. A common template used is the "Given X When Y Then Z" formula. What you have discovered is that for a lot of your specifications the "X" part stays the same. Whenever I encounter such a situation, I try to create a Fixture class to abstract this. For example, one of those classes might be a LoggedInUserFixture which sets up a logged in user and makes it available to the test.

Very often, you'll find the need to compose this fixture with other fixtures, to create the setting for your specification. For example you may need a LoggedInUserFixture and a UserWithSampleProjectSelected for a single Specification. The easiest way to do this is to create another fixture class that will setup its child fixtures and makes them individually available to your test.

I am still resisting the urge to extract a common pattern for composing fixtures and make a test framework support this.

To come back to the suggestion to use data to drive specifications, I think it is a valid and useful patterns, I usually make the data drive my fixture creation (the fixture has an appropriate constructor for data injection then). See SubSpec's Theorie feature for details.

于 2011-01-20T10:58:22.467 に答える
0

This answer is 8 years too late, but Gherkin has a way of eliminating this duplication. It's called the Scenario Background:

Feature: ...
    In order to ...
    As a ...
    I want to ...

Background:
    Given common step 1
    And common step 2

Scenario: A
    When ...
    Then ...

Scenario: B
    When ...
    Then ...

More specifically applied to your situation:

Feature: Linking facts from a report into Excel document
    In order to link facts to an Excel document
    As an user having access to report
    I want to click on fact's value in the report

Background:
    Given I am logged as admin with admin
    And I have selected Sample Project
    And I have chosen to view report presentation view containing data from factcollection1 and all periods and all clients

Scenario: Any uri item
    When I click on excel cell C2
    And I click on the value in 2 column of the row entitled any uri item
    Then Excel cell C2 should contain value some internet address

Scenario: Base64 binary item
    When I click on excel cell F3
    And I click on the value in 2 column of the row entitled base64 binary item
    Then Excel cell F3 should contain value asdf

Scenario: Boolean item
    When I click on excel cell J3
    And I click on the value in 2 column of the row entitled boolean item
    Then Excel cell J3 should contain value true

The three common Given steps are moved into the Background, and then each of your scenarios start out with a When.

Nice and tidy.

The reason this is preferable to a scenario outline is because you are dealing with parsing multiple kinds of data. Presumably there is some parsing logic behind the scenes, and parsing each data type could break in different ways during regression testing. Each test should only have one reason to fail, and your original scenarios properly capture that.

于 2019-10-22T17:04:31.163 に答える