1

Web サイトをテストするために、多数の Selenium テストを実行するように SpecFlow をセットアップしました。これはすべてうまくいきます！

SpecFlow 機能の構造化に最適化の余地があるかどうかを検討しているところです。

特定の機能のすべてのシナリオで、同じログインを使用する必要があります。これは、[BeforeScenario()] フックを使用して StepDefinition にハードコーディングしたものです。これは、シナリオをログイン情報で汚染したくないためです。試験には関係ありません。

しかし同時に、ハードコーディングされた部分を削除して、これを機能に移動したいと思います。

私の質問は 2 つの部分です。

  1. 機能の説明でログイン資格情報を指定できますか? ギブンのようなもの：

    Feature: As a user I want to be able to see my ongoing orders, and interact with them.
Given I am logged in with username abc and password xyz

Scenario: See list of ongoing order
Given I place an order
When I navigate to MyOrders page
Then I can see at least one order in the list

  2. これは良い習慣ですか？

    私が意味する機能レベルで、このようにすることは理にかなっていますか。シナリオは特定の順序に依存していないため、シナリオごとにログインする必要がなければ、より高速に実行できます。

ご意見ありがとうございます。

4

3 に答える 3

3

機能のすべてのシナリオに共通する手順については、背景を使用できます。

    Feature: As a user I want to be able to see my ongoing orders, and interact with them.

    Background:
    Given I am logged in with username abc and password xyz

    Scenario: See list of ongoing order
    Given I place an order
    When I navigate to MyOrders page
    Then I can see at least one order in the list

バックグラウンドステップの乱用が多すぎると、シナリオ間の結合が発生するため、悪い習慣になる可能性があります。

もう1つの解決策は、ログイン部分を「注文する」ステップに直接配置することです。これにより、注文するためにログインする必要があることが暗黙的に示されるため、ログインに関するすべてのノイズが除去されます。

また、「注文しました」ではなく、「注文しました」と呼ぶことをお勧めします。与えられたステップは通常、機能を使用する前に何が起こったかを説明する前提条件です（ステップの場合）

于 2013-01-10T12:54:32.940 に答える
2

When I first read your post, I thought of Dan North: Who's domain is it anyway? and that influences me to think that we should be trying to write our tests so that they stick to a single knowledge domain. As you talk about specific users and navigation and orders in a list, well its very like the example he gives in that your specification is crossing domains. This kind of leads me towards almost making your specification less specific, i.e. its not about navigating and checking a list, do you have an order or not!

Scenario: See list of ongoing order Given I am logged in with username abc and password xyz And I place an order Then should have at least one order

I wanted to give you another example link, to a post I cant find, which talks about the benefits that a team has got by actually defining some example users and what value that gives their testing. So in your business domain you might have a user called Jack who will have placed a large order in the system, and another prospective client Jill with no orders. In this way tests such as

Given I am Jack
When I search for my orders
Then I will find 1

Given I am Jill
When I search for my orders
Then I will find 0

can guarantee that you are only testing your Search functionality, and less about getting the setup in place.

I'd also suggest that you have a look at Liz Keogh: Acceptance Criteria vs Scenarios who asserts that more general broad definitions are less valuable than very specific examples. (It is Specification By Example after all :-) )

So to answer your question, I think having the specified user is a good thing, but doing it how you are doing it is heading a very complicated route.

于 2013-01-10T14:24:29.973 に答える