15 suggestions for using Cucumber

1. The Feature file should describe the Feature, not an integral part of the application

Each feature file should have a good name and focus on the Features

 

2. avoid inconsistency between features and domain Logic

One advantage of using Cucumber is that customers can be involved. Therefore, when writing your Story (Story), make sure to use your domain language. The best practice for this activity is to involve customers in writing stories.

 

3. Use the idea of organizing code to organize your features and scenarios (Scenary)

An effective way to organize features is to follow their speed. It can be expressed with 2-3 levels of granularity:

Fast: The scenario runs very Fast, for example, a tenth of a second;

Slow: The running speed is Slow, but it cannot be tolerated. It may take 1 second for each scenario;

Glacial: a time-consuming scenario;

You can use multiple methods to break down (and merge as appropriate)

1) put them in their respective features;

2) place them in their subfolders;

3) tag them)

 

4. Use tags)

Tags can organize your features and scenarios in a non-functional manner. You can use @ small, @ medium, @ large, @ hare, @ tortoise, and @ sloth. Tags can be used to organize features in a structure, but they can be run separately. Tags also help to move features/scenarios between groups, and even place feature scenarios in different groups.

Tags are used to organize features/scenarios. The advantage is that they can run at different times or at different frequencies. For example, the features of fast running can run frequently, and large and slow scenarios can run according to certain schedules.

Labels can not only place different scenarios in different groups, but also run at the same speed as the scenario:

Based on the running time: @ checkin, @ hourly, @ daily

Depending on external dependencies: @ local, @ database, and @ network

Level: @ functional, @ system, @ smoke

Others

 

5. Run features using Rake tasks

This method provides a consistent environment for running features: the same settings and parameters are used for each running. Another benefit is that it works well with continuous integration tools. Because only one single point enters the Spec, all options and parameters are encapsulated.

 

6. Do not over-use Background (stick to Given)

The larger the Background, the more difficult it is to understand each scenario. Scenarios that contain all the details are self-contained, providing readability.

 

7. Make features more independent and be able to make decisions

There should be no coupling between scenarios. The source of coupling comes from the State left between scenarios. Such a design may lead to unexpected errors. For example, a record is added to the database for a scenario, and subsequent scenarios depend on the existing record. This feature may work. However, once you change the sequence of running the scenario or run it in parallel, it may cause problems. The scenario must be completely independent.

Each time you run a scenario, you should get the same unique result. The purpose of a scenario is to describe how the system works. If you do not have sufficient confidence in the scenario, do not write it. If there is already a scenario that cannot be determined by yourself, find it and modify it.

 

8. Use Cases for Non-optimistic paths

Testing with optimistic paths is easy; edge use cases and failure scenarios require more effort and effort.

 

9. Adhere to the DRY rule: refactor and reuse Step Definition

Check whether any Step Definition irrelevant to a specific feature can be reused. As the project progresses, the library for Step Definition should be collected. Ideally, the final Step Definition can be reused across projects.

 

10. Use a library (such as Chronic) in Step Definition to parse the time

It allows you to use time in a scenario. It is very useful for relative time.

Background: Given a user signs up for a 30 day account

Scenario: access before expiry When they login in 29 days Then they will be let in

Scenario: access after expiry When they login in 31 days Then they will be asked to renew

 

11. reread and recompile and improve the scenario and steps (Step)

Once there is a chance, we need to generalize and reuse the steps. We should collect reusable libraries for the steps so that we can save things when writing additional features.

 

12. Rebuild the language and steps to better reflect the field

This is an extension from the previous point. With your understanding of the field and the language and terminology of the customer, you can promptly update the language used in the scenario.

 

13. Use compound steps to enhance your language

Compound steps can simplify features. For example:

Given/^ the user (. *) exists $/do | name |

#...

End

Given/^ I log in as (. *) $/do | name |

#...

End

To:

Given/^ (. *) is logged in $/do | name |

Given "the user # {name} exists"

Given "I log in as # {name }"

End

 

14. Use parallel Step Definition to support different features

For example, use Webrat and Selenium to run features. Place the Step Definition in a place where it cannot be automatically loaded, and then use the command line or rake task to go to require.

 

15. Avoid joint steps

"And" should not be used in each step, for example:

Given A and B

It should be divided:

Given A And B

 

 

 

 

From: http://www.agiledon.com /? Tag = cucumber

Http://www.engineyard.com/blog/2009/15-expert-tips-for-using-cucumber/: