{"id":11203,"date":"2019-04-30T17:36:19","date_gmt":"2019-04-30T17:36:19","guid":{"rendered":"http:\/\/abstracta.us\/blog\/?p=11203"},"modified":"2025-05-05T21:23:23","modified_gmt":"2025-05-05T21:23:23","slug":"a-guide-to-good-cucumber-practices","status":"publish","type":"post","link":"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/","title":{"rendered":"A Guide to Good Cucumber Practices"},"content":{"rendered":"\n<div class=\"wp-block-group is-layout-flow wp-block-group-is-layout-flow\"><div class=\"wp-block-group__inner-container\">\n<p><a href=\"https:\/\/abstracta.us\/blog\/software-testing\/what-is-bdd-and-what-does-it-mean-for-testers\/\"><span style=\"font-weight: 400;\">BDD<\/span><\/a><span style=\"font-weight: 400;\">\u00a0is a development strategy, and even if you do not follow this practice, we find it beneficial to use\u00a0<\/span><a href=\"https:\/\/docs.cucumber.io\/guides\/overview\/\"><span style=\"font-weight: 400;\">Cucumber<\/span><\/a><span style=\"font-weight: 400;\">\u00a0(or a similar tool) since it &#8220;forces you&#8221; to document your automated tests before implementing them. It\u2019s fundamental that these tests be made clear to a user who does not know the behavior of the described functionality and that they be maintainable to reduce the costs of making changes in the test steps.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">This image by Cucumber reflects the idea of combining automated tests, having a living documentation, and at the same time, still having specifications that are executable. All of this is thanks to the approach of using a tool like Cucumber.<\/span><\/p>\n<p><img decoding=\"async\" class=\"aligncenter wp-image-11182\" src=\"http:\/\/abstracta.us\/wp-content\/uploads\/2019\/04\/download-min.png\" alt=\"cucumber venn diagram\" width=\"290\" height=\"290\" \/><\/p>\n<p><span style=\"font-weight: 400;\">To work with Cucumber, you will need these files:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><b>Feature file:<\/b><span style=\"font-weight: 400;\">\u00a0text file where the acceptance criteria are written in Gherkin format. These acceptance criteria could be seen as the tests we are going to prepare.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>Step Definition:<\/b><span style=\"font-weight: 400;\">\u00a0files in the chosen programming language where Cucumber will be able to associate what actions to execute associated with each step of each acceptance criterion defined in the different features.<\/span><\/li>\n<li style=\"font-weight: 400;\"><b>Others:<\/b><span style=\"font-weight: 400;\">\u00a0Then, depending on what level we do the tests, other files may be needed. For example, if we are doing this at the level of the presentation layer, the Web GUI, then we are going to use something like Selenium, for which it would be good to follow some design pattern like Page Object. But this is something more specific and dependent on what we are testing and in this post, we want to focus on Cucumber itself.<\/span><\/li>\n<\/ul>\n<h2><span class=\"ez-toc-section\" id=\"Feature_Files_Scenarios_in_Gherkin\"><\/span><strong><span style=\"color: #00b674;\">Feature Files (Scenarios in Gherkin)<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"Creating_a_Feature\"><\/span><strong><span style=\"color: #3056a2;\">Creating a Feature<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">To begin we create a folder in the project where we will save the features that we are going to write in Gherkin. We\u2019ll base this example in a BDD exercise where we want to model the behavior of a cashier by means of functionalities in Gherkin and we will do it following these practices.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">Suppose we are interested in modeling the behavior of an ATM when we want to withdraw money:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Inside the folder, we create a file with a .feature extension (for example &#8220;withdraw-money.feature&#8221;)<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">We define a title that says what the functionality is. \u00a0For example, &#8220;Feature: Withdrawal of money&#8221;<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">We begin to write scenarios for our functionality<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">The description of a scenario is usually written as follows:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Scenario: As [concrete user]<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 I want [take a concrete action]<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 for [result or benefit]<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The important thing is to explain briefly what you want to achieve with the scenario.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/p>\n<p><span style=\"font-weight: 400;\">One way to start writing the feature can be this:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0 \u00a0 \u00a0 \u00a0\u00a0<strong>\u00a0\u00a0Feature:<\/strong>\u00a0Money Withdrawal\u00a0<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0 \u00a0 \u00a0 \u00a0\u00a0<strong>\u00a0\u00a0Scenario:<\/strong>\u00a0As an existing and enabled ATM user, I want to make a withdrawal to get money.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Some important points about feature files:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The most advisable thing is to use one feature per system functionality, making sure the Feature is specific to a single functionality in particular and is as independent as possible from other functionalities.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The best way to make our Feature files understandable to a client is to use the same language that they use to describe the functionality, therefore, it is always better to describe the actions as the client would.<\/span><\/li>\n<\/ul>\n<h3><span class=\"ez-toc-section\" id=\"i\"><\/span>\u00a0<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h3><span class=\"ez-toc-section\" id=\"Features_and_Scenarios\"><\/span><strong><span style=\"color: #3056a2;\">Features and Scenarios<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">In Gherkin, scenarios are examples of individual behavior to establish acceptance criteria, so we may be interested in writing several by functionality to observe different results and make our test more complete (it\u2019s recommended to write the positive scenarios first).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">To describe the scenarios, Gherkin sentences are used: Given, When, Then, But and And.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">The most important thing is that the steps briefly describe what you want to do in the functionality and not how you want to do it (this is the responsibility of the step definitions, explained below).<\/span><\/p>\n<p><span style=\"font-weight: 400;\">An example of a\u00a0<\/span><b>badly written scenario<\/b><span style=\"font-weight: 400;\">\u00a0is this:<\/span><\/p>\n<blockquote>\n<p><strong>Given<\/strong>\u00a0I authenticated myself with an enabled card<br \/><strong>And<\/strong>\u00a0The available balance in my account is positive<br \/><strong>And\u00a0<\/strong>the ATM has enough money<br \/><strong>And\u00a0<\/strong>the ATM has enough paper to print receipts<br \/><strong>When<\/strong>\u00a0I put the card in the ATM<br \/><strong>And\u00a0<\/strong>I input into the keyboard my card\u2019s pin<br \/><strong>And<\/strong>\u00a0I press the confirm pin button<br \/><strong>And<\/strong>\u00a0I press the button next to the option to withdraw money<br \/><strong>And<\/strong>\u00a0I enter an amount less than or equal to my available balance<br \/><strong>And<\/strong>\u00a0I press the button to confirm the withdrawal<br \/><strong>And<\/strong>\u00a0I press the button to print the receipt<\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">It\u2019s better to avoid writing scenarios in this way because it makes them very long, with many unnecessary details, so they are harder to read and understand. Another disadvantage of writing them this way is that it makes them difficult to maintain.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Here\u2019s a\u00a0<\/span><b>better and clearer way<\/b><span style=\"font-weight: 400;\">\u00a0to write the scenario:<\/span><\/p>\n<blockquote>\n<p><b>Scenario:\u00a0<\/b><span style=\"font-weight: 400;\">As an existing and enabled ATM user, I want to make a withdrawal to get money.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0I authenticated with a card enabled<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The available balance in my account is positive<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0I select the option to withdraw money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And I\u00a0<\/b><span style=\"font-weight: 400;\">enter the amount of money that is less than the amount I have available and the ATM\u2019s available balance<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Then<\/b><span style=\"font-weight: 400;\">\u00a0I get the money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The money I get is subtracted from the available balance of my account<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The system returns the card automatically<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The system displays the transaction completed message<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">Here are some important points about scenarios and steps in Gherkin:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The statements must be written in order \u201cGiven-When-Then.\u201d This is because \u2018Given\u2019 represents a precondition, \u2018When\u2019 an action and \u2018Then\u2019 a result or consequence of the action (user acceptance criteria). So writing a \u2018When\u2019 after \u2018Then\u2019, for example, would not be good conceptually and unclear.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Neither should \u2018Should-Given-Then\u2019 be repeated per stage. To extend any of the sentences, \u2018And\u2019 is used. The reason for this is that a scenario represents an individual behavior, and if we define something of the style: \u2018Given-When-Then-When&#8230;,\u2019 we can surely divide it into more than one scenario.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The sentences have to be consistent with each other and with the description of the scenario, that is, if the description of the scenario is written in the first person, the sentences should also be written in the first person.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">As much as possible, do not use many steps for a single scenario, the idea is that a user who does not know the functionality should be able to understand it by reading the scenario. The less you have to read to understand it, the better.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Write the sentences to be explanatory and brief.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Write the scenarios as we would like them to be presented to us.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">The \u2018But\u2019 statement works the same as \u2018Then,\u2019 but it is used when we want to verify that no concrete result is observed, for example:<\/span><\/li>\n<\/ul>\n<blockquote>\n<p><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0I meet a precondition<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0I execute an action<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Then<\/b><span style=\"font-weight: 400;\">\u00a0I observe this result<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>But<\/b><span style=\"font-weight: 400;\">\u00a0I should not be able to see this other result<\/span><\/p>\n<\/blockquote>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">It\u2019s very important that the scenarios are as independent as possible, that is to say: scenarios can\u2019t be coupled. For example, it\u2019s not convenient if, in a scenario, we insert records in a database, the result of following scenarios depends on the existence of those records. Having coupled scenarios can generate errors, for example, if we have to run them in parallel, or if one fails.<\/span><\/li>\n<\/ul>\n<div class=\"_form_9\">\n<h3><span class=\"ez-toc-section\" id=\"i-2\"><\/span>\u00a0<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h3><span class=\"ez-toc-section\" id=\"How_to_Separate_the_Files\"><\/span><strong><span style=\"color: #3056a2;\">How to Separate the Files?<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">When separating the features, the amount of files can be enormous, so then you have to think about how to make the division of features in different files.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">A popular option is to have a file with the features that group everything related to one aspect of the application and even organize them in directories.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">In a specific case, for an entertainment system, you might have this: In the first level we could have a folder, &#8220;Shows&#8221;. Inside, you have different features like creating, editing, deleting and everything that has to do with them. This way it is better organized and easier to locate everything and each test.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"i-3\"><\/span>\u00a0<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h3><span class=\"ez-toc-section\" id=\"Scenarios_with_Concrete_Data\"><\/span><strong><span style=\"color: #3056a2;\">Scenarios with Concrete Data<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p>BDD is somewhat similar to SBT (Sample Based Testing), in that it seeks to reduce ambiguities by showing examples. Considering this, perhaps the previous example would be better if we lower it to specific data, as in the following case:<\/p>\n<\/div>\n<blockquote>\n<p><span style=\"font-weight: 400;\"><strong>Scenario:<\/strong>\u00a0As an existing and enabled ATM user,\u00a0<\/span><span style=\"font-weight: 400;\">I want to make an extraction to get money.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0I authenticated with a card enabled<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0The available balance in my account is $10,000<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0The cashier has $100,000 in cash<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0I select the option to extract money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0I indicate that I want to extract $1,000<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Then<\/b><span style=\"font-weight: 400;\">\u00a0I get $1,000 in the form of two $500 bills<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The balance of my account becomes $9,000<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0the cashier keeps $99,000 in cash<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0The system returns the card automatically<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0The system displays the completed transaction message<\/span><\/p>\n<\/blockquote>\n<h3><span class=\"ez-toc-section\" id=\"i-4\"><\/span>\u00a0<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h3><span class=\"ez-toc-section\" id=\"In_the_first_or_third_person\"><\/span><strong><span style=\"color: #3056a2;\">In the first or third person?<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">A very common question that arises at the time of writing a scenario is the point of view that should be used. The usual question is: Should I write the scenarios in first or third person? The issue is more complex than it seems.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">The examples used in the official documentation of Cucumber use both points of view, so it is not an exact reference to solve the problem.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">Here are the arguments in favor of each:<\/span><\/p>\n<h4>The First Person<\/h4>\n<p><span style=\"font-weight: 400;\">Dan North (considered the creator of BDD), as we found in a reference in\u00a0<\/span><a href=\"https:\/\/stackoverflow.com\/questions\/34839651\/what-person-and-mood-should-i-use-in-gherkin-specflow-given-when-then-statements\"><span style=\"font-weight: 400;\">Stack Overflow<\/span><\/a><span style=\"font-weight: 400;\">, recommends the use of the first person, and in fact it\u2019s what he uses to write his scenarios in his article, \u201c<\/span><a href=\"https:\/\/dannorth.net\/introducing-bdd\/\"><span style=\"font-weight: 400;\">Introducing BDD<\/span><\/a><span style=\"font-weight: 400;\">.\u201d<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">The use of the first person allows writing the scenario to be coherent with its description, which, as mentioned above, usually follows the form &#8220;As [concrete user] I want [to perform concrete action] for [result or benefit]&#8221;.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">Given that the specific role or user for which the scenario is constructed is specified in the description, and\u00a0<\/span><b>the idea is to put oneself in the shoes of that user<\/b><span style=\"font-weight: 400;\">, the use of the first person can be a coherent form of writing.<\/span><\/p>\n<h4>The\u00a0Third Person<\/h4>\n<p><span style=\"font-weight: 400;\">The defenders of this position argue that\u00a0<\/span><b>the use of the first person makes the scenario reader lose reference to the role or the user that is being talked about.<\/b><span style=\"font-weight: 400;\">\u00a0If I write in a step &#8220;I delete an article from the system,&#8221; who is the one that is doing it? An administrator, a particular user? A set of roles?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In some way, the use of the third person diminishes the risk or the difficulty of the reader making erroneous assumptions about who is the stakeholder(s) involved.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It\u2019s also argued that the use of the third person presents the information in a more formal and objective way.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/p>\n<h4>Conclusion<\/h4>\n<p><b>There is no general rule about the point of view to use to write the scenarios.<\/b><\/p>\n<p><span style=\"font-weight: 400;\">The important thing at this point, as already mentioned, is to maintain the consistency between the description of the scenario and its steps (not to alternate points of view), to respect the criteria used in the case that we are adding scenarios to an existing project and to favor clarity of what is written.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"i-5\"><\/span>\u00a0<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h3><span class=\"ez-toc-section\" id=\"Other_Key_Words_to_Describe_the_Scenarios\"><\/span><strong><span style=\"color: #3056a2;\">Other Key Words to Describe the Scenarios<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h3>\n<h4>Background<\/h4>\n<p><span style=\"font-weight: 400;\">If in all the scenarios of the same feature, some preconditions are met, it is much more practical to use a Background than to write the same thing several times. This serves as a series of steps that will be executed before all the scenarios of the feature. Let&#8217;s see an example:<\/span><\/p>\n<blockquote>\n<p><span style=\"font-weight: 400;\"><strong>Feature:<\/strong>\u00a0Money Withdrawal<\/span><\/p>\n<p><b>Background:<\/b><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0The credit card is enabled<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The available balance in my account is positive<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0the ATM has enough money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Scenario:<\/b><span style=\"font-weight: 400;\">\u00a0&#8230;<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">It is recommended that the Background be as short as possible in terms of the number of steps, because if it is very long, it can be difficult to understand the scenarios that follow. It\u2019s always better to have scenarios be as self-contained as possible, and in case you have a Background, make it as short as possible.<\/span><\/p>\n<h4>Scenario Outline<\/h4>\n<p><b>Scenario Outline<\/b><span style=\"font-weight: 400;\">\u00a0is a type of scenario where input data is specified. They are very practical because, thanks to this, it\u2019s not necessary to write a scenario by input data.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For example:<\/span><\/p>\n<blockquote>\n<p><b>Scenario outline:<\/b><span style=\"font-weight: 400;\">\u00a0Withdraw money with different card keys.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0The credit card is enabled<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0The available balance in my account is positive<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0the ATM has enough money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0I put the card in the ATM<\/span><\/p>\n<p><b>And<\/b><span style=\"font-weight: 400;\">\u00a0Enter the &lt;pin&gt; of the card<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u2026<\/span><\/p>\n<p><b>Examples: \u00a0<\/b><\/p>\n<p><b>\u00a0|\u00a0<\/b><span style=\"font-weight: 400;\">pin<\/span><b>\u00a0|<\/b><\/p>\n<p><b>\u00a0|\u00a0<\/b><span style=\"font-weight: 400;\">1234\u00a0<\/span><b>| \u00a0<\/b><\/p>\n<p><b>\u00a0|\u00a0<\/b><span style=\"font-weight: 400;\">9876<\/span><b>\u00a0|<\/b><\/p>\n<\/blockquote>\n<h4>Doc Strings<\/h4>\n<p><span style=\"font-weight: 400;\">Doc Strings are useful to add strings of long characters to a step in a neater way.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">To use them, you must add the desired text in the step between three quote marks (&#8220;&#8221;&#8221;). For example:<\/span><\/p>\n<blockquote>\n<p><b>Scenario outline: &#8230;<\/b><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0&#8230;<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0&#8230;<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Then<\/b><span style=\"font-weight: 400;\">\u00a0I get money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0the Confirmation message is displayed with the text:<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0&#8220;&#8221;&#8221;<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0Dear Customer:<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0The following amount has been withdrawn from your account # &lt;account&gt;: &lt;amount&gt;.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0Thank you for using our services.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0&#8220;&#8221;&#8221;<\/span><\/p>\n<p><b>Examples: \u00a0\u00a0<\/b><\/p>\n<p><b>\u00a0\u00a0\u00a0|\u00a0<\/b><span style=\"font-weight: 400;\">pin \u00a0| account \u00a0\u00a0\u00a0| amount |<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0| 1234 | 112235489 | 5000 \u00a0|<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0| 9876 | 668972214 | 6000 \u00a0|<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">As you can see in the previous example, a Doc String (which is in itself an input data) can be used in combination with other input data to show data specific to the scenario that is being executed.<\/span><\/p>\n<h4>Data Tables<\/h4>\n<p><span style=\"font-weight: 400;\">Data Tables, in their structure and usefulness, are very similar to Scenario Outlines. Their two main differences are:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">Data Tables are defined at the step level and not at the scenario level, so they serve to pass input data to a single step within the scenario.<\/span><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\">It\u2019s not necessary to define a head, although it is useful and advisable to be able to reference the data more easily.<\/span><\/li>\n<\/ul>\n<p><span style=\"font-weight: 400;\">Example of the use of Data Tables:<\/span><\/p>\n<blockquote>\n<p><b>Scenario:\u00a0<\/b><span style=\"font-weight: 400;\">Withdraw money with different card keys.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>Given<\/b><span style=\"font-weight: 400;\">\u00a0The credit card is enabled<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">The available balance in my account is positive<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And<\/b><span style=\"font-weight: 400;\">\u00a0the ATM has enough money<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>When<\/b><span style=\"font-weight: 400;\">\u00a0I put the card in the cashier<\/span><span style=\"font-weight: 400;\"><br \/><\/span><b>And\u00a0<\/b><span style=\"font-weight: 400;\">I enter the following &lt;pin&gt; and get the result &lt;result&gt;:<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0| pin \u00a0| result\u00a0 \u00a0 \u00a0 \u00a0|<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0 | 1234 | Error \u00a0\u00a0\u00a0\u00a0|<\/span><\/p>\n<p><span style=\"font-weight: 400;\">\u00a0\u00a0| 9876 | OK\u00a0 \u00a0 \u00a0 \u00a0 \u00a0|<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">In the previous example, we added a second column &#8220;result&#8221;, to indicate the expected result according to the entered PIN (&#8220;1234&#8221; is incorrect and &#8220;9876&#8221; is correct). It is not necessary to use the Data Table in that way, but it is included as an example of how the input data can be used in a scenario.<\/span><\/p>\n<h4>Languages<\/h4>\n<p><span style=\"font-weight: 400;\">Cucumber offers the possibility of writing the scenarios in different human languages, following the same conventions that we normally use in English.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">To make use of this feature, the functionality must be headed with &#8220;# language:&#8221;, followed by the dialect code to be used (for example, &#8220;# language: es&#8221;, for Spanish).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">In the official Cucumber documentation, you can find all the necessary information to use this feature, including the code of each dialect and the words that should be used for each language to replace the typical ones.<\/span><\/p>\n<h4>Tags<\/h4>\n<p><span style=\"font-weight: 400;\">On certain occasions, it may happen that we don\u2019t want to execute all the scenarios of our test, but rather group certain scenarios and execute them separately. Cucumber provides a way to configure this by means of tags. The tags are annotations that serve to group and organize scenarios and even features, these are written with the @ symbol followed by a significant text, examples:<\/span><\/p>\n<blockquote>\n<p><span style=\"font-weight: 400;\">@gui<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>Feature:<\/strong>\u00a0\u2026<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">@SmokeTest @wip\u00a0<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>Scenario:<\/strong>\u00a0\u2026<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">@RegressionTest<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>Scenario:<\/strong>\u00a0&#8230;<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">It is important to note that the tags that we specify to the titles of the Feature files will be inherited by the scenarios of the same, including Scenario Outlines.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">If we have a Scenario outline under a tag, all the data examples that the scenario has will be executed under that tag.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">Having assigned our tags, there are many ways to configure them in the execution in the tag section of @CucumberOptions. Some examples:<\/span><\/p>\n<p><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@SmokeTest&#8221;}<\/strong>\u00a0Execute all scenarios under the @SmokeTest tag<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@gui&#8221;}<\/strong>\u00a0Execute all the scenarios under the @gui tag, as in the example we have a feature under this tag, all the scenarios of that feature will be executed.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@SmokeTest, @wip&#8221;}<\/strong>\u00a0Execute all scenarios that are under the @SmokeTest tag or under the @wip tag (OR condition).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@SmokeTest&#8221;, &#8220;@RegressionTest&#8221;}<\/strong>\u00a0Execute all scenarios that are under the @SmokeTest and @RegressionTest tags (AND condition).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;~@SmokeTest&#8221;}<\/strong>\u00a0ignores all scenarios under the @SmokeTest tag<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@RegressionTest, ~@SmokeTest&#8221;}<\/strong>\u00a0executes all scenarios under the @RegressionTest tag, but ignores all scenarios under the @SmokeTest tag<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><strong>tags = {&#8220;@gui&#8221;, &#8220;~@SmokeTest&#8221;, &#8220;~@RegressionTest&#8221;}<\/strong>\u00a0ignores all the scenarios under the tag @SmokeTest and @RegressionTest but executes all those under the tag &#8220;@gui&#8221;, if we follow the example it&#8217;s like running all the scenarios of the feature that are not under any other tag.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">In short, tags are not only useful for organizing and grouping our scenarios\/features (which contributes a lot to the clarity of the test), but also allow us to execute them selectively, such as, for example, executing the fastest scenarios more frequently.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Step_Definition_Implementation_of_the_Steps\"><\/span><strong><span style=\"color: #00b674;\">Step Definition (Implementation of the Steps)<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">What we did previously was the specification of the steps of our scenarios, we describe what processes our test will follow, but we do not define how we want it to be done. This becomes the responsibility of the implementation of the Gherkin sentences that we write in the scenarios (step definitions).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">The step definitions serve Cucumber as a translation of the steps we write in actions to execute to interact with the system.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">Although the examples that will be given below for the implementation of the steps are developed in Java, it should be mentioned that Cucumber can also be used with JavaScript, Ruby, C ++ and other languages.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">To start writing step definitions, if we are working on an IDE with dependencies of Gherkin and Cucumber already installed, it will suggest us to implement them (they will appear underlined), and it will allow us to create a .java file or choose one where we already have steps implemented. Choosing any of these two options will generate a method in the class, for example if we decide to create a step definition for the step:<\/span><\/p>\n<blockquote>\n<p><span style=\"font-weight: 400;\"><strong>Given<\/strong>\u00a0The credit card is enabled<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">We will automatically generate a method with an annotation, where the header text will match the description of the step:<\/span><\/p>\n<blockquote>\n<p><span style=\"font-weight: 400;\">@Given(&#8220;^The credit card is enabled$&#8221;)<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0public void verifyEnabledCard() throws Throwable {<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Write code here that turns the phrase above into concrete actions\u00a0<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0throw new PendingException();<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">}<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">In the case that the step includes input data defined through Scenario Outline or Data Tables, these data are included in the annotation as regular expressions, and in the method as received parameters:<\/span><\/p>\n<blockquote>\n<p><span style=\"font-weight: 400;\">@When(&#8220;^Enter the \\&#8221;([0-9]+)\\&#8221; of the card $&#8221;)<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0public void enterPIN(int pin) throws Throwable {<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ Write code here that turns the phrase above into concrete actions\u00a0<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">\u00a0\u00a0\u00a0\u00a0\u00a0throw new PendingException();<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">}<\/span><\/p>\n<\/blockquote>\n<p><span style=\"font-weight: 400;\">Automatically when we do this, the step in the feature (the sentence in Gherkin) already recognizes where the implementation is. Here are some important points when implementing step definitions:<\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\"><br \/><\/span><span style=\"font-weight: 400;\">The most advisable thing is to create step definitions that only have to be implemented once and reused in many scenarios (even of different features).<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/p>\n<p><span style=\"font-weight: 400;\">This is practical not only to save the amount of code that has to be written, it also contributes a lot to the maintainability of the tests since it will eventually be less the number of step definitions that we will have to modify in any case.<\/span><span style=\"font-weight: 400;\"><br \/><\/span><\/p>\n<p><span style=\"font-weight: 400;\">One way to reuse step definitions is to define them in Scenario outlines and parameterize them.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Further_Resources\"><\/span><strong><span style=\"color: #00b674;\">Further Resources<\/span><\/strong><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">We leave you some references in case you want to continue reading about BDD, good Cucumber practices, or Gherkin:<\/span><\/p>\n<ul>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/automationpanda.com\/2017\/01\/25\/bdd-101-introducing-bdd\/\"><span style=\"font-weight: 400;\">https:\/\/automationpanda.com\/2017\/01\/25\/bdd-101-introducing-bdd\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/hiptest.com\/docs\/writing-scenarios-with-gherkin-syntax\/\"><span style=\"font-weight: 400;\">https:\/\/hiptest.com\/docs\/writing-scenarios-with-gherkin-syntax\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/docs.cucumber.io\/gherkin\/reference\/\"><span style=\"font-weight: 400;\">https:\/\/docs.cucumber.io\/gherkin\/reference\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/www.foreach.be\/blog\/9-tips-improving-cucumber-test-readability\"><span style=\"font-weight: 400;\">https:\/\/www.foreach.be\/blog\/9-tips-improving-cucumber-test-readability<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/saucelabs.com\/blog\/write-great-cucumber-tests\"><span style=\"font-weight: 400;\">https:\/\/saucelabs.com\/blog\/write-great-cucumber-tests<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/blog.codeship.com\/cucumber-best-practices\/\"><span style=\"font-weight: 400;\">https:\/\/blog.codeship.com\/cucumber-best-practices\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/automationpanda.com\/2018\/02\/03\/are-gherkin-scenarios-with-multiple-when-then-pairs-okay\/\"><span style=\"font-weight: 400;\">https:\/\/automationpanda.com\/2018\/02\/03\/are-gherkin-scenarios-with-multiple-when-then-pairs-okay\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/automationpanda.com\/2018\/01\/31\/good-gherkin-scenario-titles\/\"><span style=\"font-weight: 400;\">https:\/\/automationpanda.com\/2018\/01\/31\/good-gherkin-scenario-titles\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/automationpanda.com\/2017\/01\/30\/bdd-101-writing-good-gherkin\/\"><span style=\"font-weight: 400;\">https:\/\/automationpanda.com\/2017\/01\/30\/bdd-101-writing-good-gherkin\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"http:\/\/toolsqa.com\/cucumber\/background-in-cucumber\"><span style=\"font-weight: 400;\">http:\/\/toolsqa.com\/cucumber\/background-in-cucumber<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/www.engineyard.com\/blog\/15-expert-tips-for-using-cucumber\"><span style=\"font-weight: 400;\">https:\/\/www.engineyard.com\/blog\/15-expert-tips-for-using-cucumber<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"http:\/\/toolsqa.com\/cucumber\/cucumber-tags\/\"><span style=\"font-weight: 400;\">http:\/\/toolsqa.com\/cucumber\/cucumber-tags\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/stackoverflow.com\/questions\/34839651\/what-person-and-mood-should-i-use-in-gherkin-specflow-given-when-then-statements.\"><span style=\"font-weight: 400;\">https:\/\/stackoverflow.com\/questions\/34839651\/what-person-and-mood-should-i-use-in-gherkin-specflow-given-when-then-statements.<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><a href=\"https:\/\/www.spritecloud.com\/2018\/03\/the-3-most-common-mistakes-writing-gherkin-features\/\"><span style=\"font-weight: 400;\">https:\/\/www.spritecloud.com\/2018\/03\/the-3-most-common-mistakes-writing-gherkin-features\/<\/span><\/a><\/li>\n<li style=\"font-weight: 400;\"><span style=\"font-weight: 400;\"><a href=\"https:\/\/automationpanda.com\/2017\/01\/18\/should-gherkin-steps-use-first-person-or-third-person\">https:\/\/automationpanda.com\/2017\/01\/18\/should-gherkin-steps-use-first-person-or-third-person<\/a><\/span><\/li>\n<\/ul>\n<hr \/>\n<h2><span class=\"ez-toc-section\" id=\"Recommended_for_You\"><\/span><span style=\"font-weight: 400;\">Recommended for You<\/span><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><a href=\"http:\/\/abstracta.us\/blog\/devops\/webinar-summary-bdd-cd-lisa-crispin\/\">Webinar Summary: BDD and CD with Lisa Crispin<\/a><br \/><a href=\"http:\/\/abstracta.us\/blog\/test-automation\/when-to-automate-a-test\/\"><span style=\"font-weight: 400;\">When to Automate a Test?<\/span><\/a><br \/><!-- Go to www.addthis.com\/dashboard to customize your tools --><script src=\"\/\/s7.addthis.com\/js\/300\/addthis_widget.js#pubid=ra-58d80a50fc4f926d\" type=\"text\/javascript\"><\/script><\/p>\n<\/div><\/div>\n","protected":false},"excerpt":{"rendered":"<p>BDD\u00a0is a development strategy, and even if you do not follow this practice, we find it beneficial to use\u00a0Cucumber\u00a0(or a similar tool) since it &#8220;forces you&#8221; to document your automated tests before implementing them. It\u2019s fundamental that these tests be made clear to a user&#8230;<\/p>\n","protected":false},"author":55,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61],"tags":[68,99,222,314],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v14.0.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>A Guide to Good Cucumber Practices | Abstracta<\/title>\n<meta name=\"description\" content=\"We&#039;ll share some good Cucumber practices, especially when writing scenarios using Gherkin, and clarify some BDD concepts for better scenarios.\" \/>\n<meta name=\"robots\" content=\"index, follow\" \/>\n<meta name=\"googlebot\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<meta name=\"bingbot\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"A Guide to Good Cucumber Practices | Abstracta\" \/>\n<meta property=\"og:description\" content=\"We&#039;ll share some good Cucumber practices, especially when writing scenarios using Gherkin, and clarify some BDD concepts for better scenarios.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\" \/>\n<meta property=\"og:site_name\" content=\"Blog about AI-powered quality engineering for teams building complex software | Abstracta\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/AbstractaQA\/\" \/>\n<meta property=\"article:published_time\" content=\"2019-04-30T17:36:19+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2025-05-05T21:23:23+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/abstracta.us\/wp-content\/uploads\/2019\/04\/good-cucumber-practices-min.png\" \/>\n\t<meta property=\"og:image:width\" content=\"560\" \/>\n\t<meta property=\"og:image:height\" content=\"315\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@AbstractaUS\" \/>\n<meta name=\"twitter:site\" content=\"@AbstractaUS\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebSite\",\"@id\":\"https:\/\/abstracta.us\/blog\/#website\",\"url\":\"https:\/\/abstracta.us\/blog\/\",\"name\":\"Blog about AI-powered quality engineering for teams building complex software | Abstracta\",\"description\":\"AI-powered quality engineering\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":\"https:\/\/abstracta.us\/blog\/?s={search_term_string}\",\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"en-US\"},{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/#primaryimage\",\"inLanguage\":\"en-US\",\"url\":\"http:\/\/abstracta.us\/wp-content\/uploads\/2019\/04\/download-min.png\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/#webpage\",\"url\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\",\"name\":\"A Guide to Good Cucumber Practices | Abstracta\",\"isPartOf\":{\"@id\":\"https:\/\/abstracta.us\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/#primaryimage\"},\"datePublished\":\"2019-04-30T17:36:19+00:00\",\"dateModified\":\"2025-05-05T21:23:23+00:00\",\"author\":{\"@id\":\"https:\/\/abstracta.us\/blog\/#\/schema\/person\/3cc530c545cab16fae6829f65fe4419e\"},\"description\":\"We'll share some good Cucumber practices, especially when writing scenarios using Gherkin, and clarify some BDD concepts for better scenarios.\",\"breadcrumb\":{\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/abstracta.us\/blog\/\",\"url\":\"https:\/\/abstracta.us\/blog\/\",\"name\":\"Home\"}},{\"@type\":\"ListItem\",\"position\":2,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/\",\"url\":\"https:\/\/abstracta.us\/blog\/testing-tools\/\",\"name\":\"Testing Tools\"}},{\"@type\":\"ListItem\",\"position\":3,\"item\":{\"@type\":\"WebPage\",\"@id\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\",\"url\":\"https:\/\/abstracta.us\/blog\/testing-tools\/a-guide-to-good-cucumber-practices\/\",\"name\":\"A Guide to Good Cucumber Practices\"}}]},{\"@type\":[\"Person\"],\"@id\":\"https:\/\/abstracta.us\/blog\/#\/schema\/person\/3cc530c545cab16fae6829f65fe4419e\",\"name\":\"Abstracta Team\",\"image\":{\"@type\":\"ImageObject\",\"@id\":\"https:\/\/abstracta.us\/blog\/#personlogo\",\"inLanguage\":\"en-US\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/6cab9c9f3dec946bd8867fdb2abbd10a?s=96&d=blank&r=g\",\"caption\":\"Abstracta Team\"},\"description\":\"We are a technology solutions company specializing in software testing, custom software development, and AI-driven software solutions. We provide top-notch, holistic solutions to enable continuous delivery of high-quality software. Our purpose is to co-create first class software, generating opportunities for development in our communities to improve people's quality of life. Organizations such as BBVA Financial Group, CA Technologies and Shutterfly turn to us for comprehensive quality solutions, from rigorous testing to innovative AI copilots and bespoke software development. Sharing our learnings with the community is rooted in our values. That is why we believe in collaborating with the IT community by sharing quality content, courses, and promoting thought leadership events. Recognized with several awards, we are committed to quality, innovation, and customer satisfaction. Our experienced team, dedicated to continuous learning and improvement, has earned the trust of numerous clients worldwide, from startups to Fortune 500 companies. We are a fast-growing company, and we are looking for proactive and talented people, who can assume responsibilities, bring new ideas, and who are as excited as we are about our mission of building high-quality software. If you are interested in joining the team, apply here https:\/\/abstracta.us\/why-us\/careers.\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","_links":{"self":[{"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/posts\/11203"}],"collection":[{"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/users\/55"}],"replies":[{"embeddable":true,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/comments?post=11203"}],"version-history":[{"count":13,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/posts\/11203\/revisions"}],"predecessor-version":[{"id":16023,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/posts\/11203\/revisions\/16023"}],"wp:attachment":[{"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/media?parent=11203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/categories?post=11203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/abstracta.us\/blog\/wp-json\/wp\/v2\/tags?post=11203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}