Too many variables in my Examples

[Gianni Pucciani]

Hello,

I'd like to know what are the good practices to keep our Examples table reasonably small.
We are automating end-to-end business scenarios who include up to 15 variables (i.e. columns in the Examples section).
But, all the variables have an impact on the final result, so I cannot consider them background noise.
Does anybody have any suggestions/examples on how to reduce these tables to make them more business readable?

Thanks in advance for your feedback!

[Andrew Premdas]

Good practice is not to use example tables at all in my opinion. (others will disagree)

My reasoning is as follows

All examples are open to a wide range of interpretation, they are after all just a table of data values. Thus they are inherently prone to ambiguity. The bigger the table and the more values you have the greater the ambiguity.

In addition all data values are prone to typos, both when creating the scenario and even more so when fixing broken scenarios. If you have a table with 15 columns how are you going to be sure that every value is correct?

Examples are only useful when trying to get people to articulate WHAT you are trying to do. Once you have some idea of WHAT you are trying to do and WHY its important that you do it you should replace examples with scenarios that clearly explain the business context.

Simple example

When I login with id <id> and password <password>

Then I should see <result>

Examples

id password result

fred fredpass Welcome Fred

sally 123        password to short
...

becomes

Scenario: Login with good creds

   When I login with good creds

   Then I should be logged in

Scenario: Login with bad password

   When I login with a bas password

   Then I should not be logged in

Scenario: Register with to short a password

  When I register

  And I provide a short password

  Then I should be told my password is too short

etc

etc

By breaking example tables up into small succinct scnenarios you achieve the following

1. You write simpler cukes which are much easier to maintain

2. You express what you are doing with greater clarity and simplicity

3. You discover things that you haven't thought about e.g. registering with a short password vs using a short password and further e.g. change password, using same password again etc etc.

This is a really trivial example, you have something much more complicated with much more data. You have a tremendous amount to learn and express from this. It may be hard, but if you want clear and simple software that says what it does and does what it says then its definitely worth the effort.

Hope thats useful

All best

Andrew

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Yogesh Chaudhari]

Hi Gianni,

Have a look at 'Map data tables to domain objects' on this link: http://blog.czeczotka.com/2014/08/17/writing-cucumber-jvm-step-definitions/

You probably need this.

Regards,

Yogesh

To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.