what is the benefit of "scenario" over "scenario outline" in cucumber?

Question

I know the difference between scenario and scenario outline from here.

Scenario states the general point of test in more abstract way. Meanwhile, the scenario outline facilitates performing scenario with several examples.

So, we usually write a feature file as below. It starts with scenario and then gets completed with scenario outline.

Feature: Title of your feature I want to use this template for my feature file

 Scenario: Eating
  Given I have "N" cucumbers
  When I eat "K" ones of them
  Then I will have "N-K" ones

Scenario Outline: eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |
    |  20   |  5  |  15  |

But it doesn't make that much sense for me. I believe Scenario outline is more understandable, and therefore there is no need to have express the general point of view of the test with the scenario.

Do you agree with me?

I mean, what does the scenario do, which scenario outline cannot do?

I suggest to go with simpler one

Scenario Outline: eating
  Given there are <start> cucumbers
  When I eat <eat> cucumbers
  Then I should have <left> cucumbers

  Examples:
    | start | eat | left |
    |  12   |  5  |  7   |
    |  20   |  5  |  15  |

I know it leads to an error, but i think it would be better if cucumber team totally remove the concept of scenario, and instead support the scenario outline more.

Answer 1

You couldn't be more wrong.

What you are doing is following an anti-pattern to make your step definitions more succinct. In doing this you are

1) Dramatically reducing the amount of information that you step definitions communicate

2) Increasing your runtime (example tables encourage running to many examples. In your table you have two rows that do exactly the same thing)

3) Create maintenance problems for all future executions of the scenario.

The only reasons to use example tables with Cucumber is to make it easier for you to collaborate with stakeholders. Here we use outlines and examples that give a rough summary of what you want to achieve in a particular area. Once you have these you should be extracting individual scenarios to explore and document particular rules and policies that each of the examples represent. So as part of the implementation process you are improving the outline scenarios into better quality individual scenarios

If we take a better example table

user           | password  | result
not_registered |  goodpass | user not found
registered     |  badpass  | bad password
registered     | goodpass  | logged in

then we are much better off breaking this into individual scenarios than keeping things in a table for so many reasons.

First of all we can document each policy in greater detail. If we take the registered badpass bad password example we could have

Scenario: Login with bad password
  Given I am registered
  When I login with a bad password
  Then I should see a bad password error

Now we might decide that showing a bad password error is not a good idea because it helps people hack accounts by confirming that the registered account exists. So we would improve this scenario too

Scenario: Login with bad password (show login error only to prevent account identification)
  Given I am registered
  When I login with a bad password
  Then I should see a bad login error

The individual scenario provides the opportunity to add documentation and to use a different step. Updating the example table communicates much less (you have to guess why bad password became bad login)

registered     |  badpass  | bad login

Other reasons to not use example tables are

1. The step definitions are much much harder to write.
2. The step definitions are much harder to reuse
3. Example values in tables are error prone, if I change 24 to 23 was I fixing a typo or changing a fundamental business rule
4. Example values are almost always repetitions of values in the codebase
5. Example values need updating when the codebase changes

Lets have a quick look at 5.

Say we have a weak password '12345' and a strong password re432uee8l.

If we use example tables we end up with hard coded passwords in the table e.g.

registered | re432uee8l | logged in

Now if we change our business rule to say that our strong password must have a symbol in it, we have to change every strong password example in our set of features.

Having used Cucumber since the very beginning I strongly recommend that

Implemented scenarios (ones that you should be running after every 'push|build|deploy` should have no examples, and no outlines). If you are running outlines and examples you are running scenarios that have not been completed.

Answer 2

It's not about what one can do over the other, it's about making the scenario as simple and easy to understand as possible.

If there is only one example, simplify it and don't use an examples table, it makes it easier to read and understand