BDD Best Practices

1. BDD scenarios should be written in collaboration with product owners, developers and testers.
2. Specify the intent and the behavior of the system when defining scenarios.
3. Include the intent of the scenario in the scenario title.
4. Describe the behavior that is wanted from the system using Given/When/Then (GWT) statements. Do not provide technical implementation of the behavior.
5. Use realistic user names/personas when writing scenarios. 
6. Write scenarios in such a way that it's easy to read and understand by anyone in the team. 
7. Every scenario should be independent of each other. There should not be any coupling between scenarios.
8. Write scenarios for edge cases and failure cases as well. Don’t just focus on happy path scenarios.

9. Always think about your stakeholders when defining scenarios.

10. Write Steps Declaratively. Avoid writing brittle Scenarios. Don't provide any UI interaction details like button clicks in GWT scenarios. These details should be pushed into automation implementation. Example:

Brittle Scenario	Readable Scenario
Scenario: Successful login Given a user “user1" with password "xyz" And I am on the login page And I fill in "User name" with “user1" And I fill in "Password" with "xyz" When I click "Log in“ button Then I should see "Welcome, User1"	Scenario: Successful login Given Jane Smith has an account When she logs in with valid credentials Then she should see the welcome message

Feature file and Step file Implementation

• There is no One-To-One mapping between Feature File and Step File.

• Multiple feature file can be implemented by single Step File having methods with matching pattern for each of the steps in those Feature Files.

•  Single Feature File can be implemented by multiple Step Files as the Step Methods can be distributed among those Step Files.
  • Only restriction is that all those Step Files are to be in the same package.
    
    
• Matching Step Methods are searched across the specified package. Hence even if we specify two differently named methods with same regex pattern in two different Step Files in same package, then a runtime error will occur.
  
  
• Step Methods are reusable. Meaning, for same Steps written in different Step Scenarios or even different Feature Files (generally Given steps can be like that) we need to write only one Step Method.