صياغة Gherkin وميزاتها

Gherkin is a plain-language parser used by Behavior-Driven Development (BDD) tools like Cucumber. It helps describe software behavior in a human-readable format.

This makes it easier for everyone—developers, testers, and business stakeholders—to understand and agree on what the software should do. Gherkin uses a specific set of keywords to structure these descriptions.

The Feature keyword is the starting point of any Gherkin document. It describes a high-level capability or a specific area of the application.

• Think of it as the main goal or business requirement you are testing.
• It should have a clear, concise title.
• An optional description can follow, providing more context.
• Each .feature file typically contains one Feature.

Here’s how you define a Feature. Notice the optional description lines that add clarity, explaining the 'who', 'what', and 'why'.

Within a Feature, individual test cases are called Scenarios. A Scenario describes a single, concrete example of behavior.

For repetitive tests with different data, Scenario Outline is used. It runs the same steps multiple times, substituting values from an Examples table (which we'll cover in future lessons).

A Scenario typically follows the "Given-When-Then" structure. It's a specific example of how the feature behaves under certain conditions.

The Given keyword is used to describe the initial state or context of the system. It sets up the prerequisites for the scenario.

• Think of it as the "precondition" for your test.
• It should describe something that has already happened.
• Example: Given the user is logged in or Given a product exists with price $10.

The When keyword describes the action or event that triggers the behavior under test. This is typically an interaction by the user or an external system.

• It's the "trigger" for the behavior.
• It should describe a single, observable action.
• Example: When the user clicks the "Add to Cart" button or When the payment is processed.

The Then keyword describes the expected outcome or result after the When action. It's how you verify the system's behavior.

• This is the "assertion" part of your test.
• It should describe an observable change in the system.
• Example: Then the item should be added to the cart or Then the order status should be "Completed".

Here's a complete Scenario showing Given, When, and Then working together. Notice how And can be used to extend any step for better readability.

In Gherkin, steps follow a logical flow to describe a behavior. Arrange the keywords in the correct order for a typical scenario.

You've learned the core elements of Gherkin syntax!

• Feature defines a high-level capability.
• Scenario describes a single example of behavior.
• Given sets the initial context.
• When describes the action or event.
• Then verifies the expected outcome.
• And and But are used to extend steps for readability.

This human-readable language bridges the gap between technical and non-technical team members, ensuring everyone understands the desired system behavior.