CODEWITHSUNDEEP
automated-testscucumberbdd
Ehtesham Ahmed
Ehtesham Ahmed

Reputation: 69

Optimize complex scenario in Cucumber

I have been working on an automation project where I have to write cucumber test for search filter. Search filter works dynamically where parameters are nested - next parameter are populated based on previous parameter e.g. On selecting "Subscribers" next parameters in dropdown are "Name", "City", "Network". Likewise, on selecting "Service Desk", parameters in subsequent dropdown are "Status", "Ticket no.", "Assignee". I am using Scenario Outline as below:

Scenario Outline: As a user, I can search records
   Given I am on search page
   When I search on "<category>" and "<nestedfilter>"
   Then I see records having "<category>" category

Examples:
|category    |nestedfilter|
|Subscribers |Name        |
|Subscribers |City        |
|Subscribers |Network     |
|Service Desk|Status      |
|Service Desk|Ticket no.  | 
|Service Desk|Assignee    |

The filter could be more complex as there could be more nested filters based on previous nested filters.

All I need to know if there could be a more efficient way to handle this problem? For example passing data table to step_definition for which I am not too sure.

Thanks

Upvotes: 1

Views: 2052

Answers (3)

Lunivore
Lunivore

Reputation: 17602

The fact that you have a drop-down and nested filters is an implementation detail, which describes how the user is trying to achieve what they want to achieve.

If you think of what you're trying to do as examples of how the system behaves, rather than tests, it might be easier. You're not looking for something exhaustive. You also want your scenarios to be specific, so that you're illustrating them with realistic data and concrete examples. If you would commonly have some typical data available, that's a perfect thing to set up using Background.

So for instance, I might have scenarios like:

Background:
  Given I have subscribers
  | Name | City   | Network | Status | etc.
  | Bob  | Rome   | ABC     | Alive  | ...
  | Sam  | Berlin | ABC     | Dead   | ...
  | Sue  | Berlin | DEF     | Dead   | ...
  | Ann  | Berlin | DEF     | Alive  | ...
  | Jon  | London | DEF     | Dead   | ...

Scenario: First level search

  Given I'm on the search page
  When I search for Subscribers who are in Rome
  Then I should see Bob
  But not Sue or Jon.

Scenario: Second level search

  Given I'm on the search page
  When I search for Subscribers in Berlin on the ABC network
  Then I should see Sam
  But not Sue or Ann

etc.

The full-system scenarios should be just enough to understand what's going on. Don't use BDD for regression. It can help with that, but scenarios will rapidly become slow and unmaintainable if you try to cover every case. Delegate to integration and unit tests where appropriate (see "the testing pyramid").

Upvotes: 0

diabolist
diabolist

Reputation: 4099

A common mistake with Cucumber is to use Scenario Outline and example tables to do some sort of semi-exhaustive testing. This tends to hide lots of interesting things about the functionality being developed.

I would start writing single features for the searches you are working with and explore what those searches are and why they are important. So if we start with your first one we get ...

Note: all of the following assumes a background step Given I am searching

When I search on subscribers and name
Then I should see records for subscribers

and with the second one

When I search on subscribers and city
Then I should see records for subscribers

Now it becomes clear that there is a serious flaw in these scenarios, as both scenarios are looking for the same result.

So what you are actually testing is that

  1. The subscribers search has name and city filters
  2. A subscriber search should return subscriber results

Now you can refactor and get

When I do a subscriber search
Then I should see city, name, network filters

When I do a subscriber search
Then I should only see subscriber results

note: This is already much more efficient as you have reduced the number of scenarios from 3 to 2, and reduced the number of searches you have to do from 3 to 1.

Now I have no idea if this is what you want to do, but this is what your current scenario is doing. However because you are using an Outline and Example tables you can't see this.

Upvotes: 0

Thomas Sundberg
Thomas Sundberg

Reputation: 4323

If you really need the order of your items to be preserved, use a data table instead of a scenario outline.

A scenario outline is a shorthand notation for multiple scenarios. The execution of each scenario is not guaranteed. Or at least it would be a mistake to assume a specific execution order. The order of the items in a data table will not change if you use a List as argument and therefore a lot safer in your case.

Upvotes: 1

Related Questions