Cucumber

Acceptance testing vs unit test

It’s sometimes said that unit tests ensure you build the thing right, whereas acceptance tests ensure you build the right thing.

Cucumber.

The acceptance testing tool.

Source of Truth

For many teams, the Cucumber feature files become the definitive source of truth as to what the system does.

Scenarios

Scenarios are written before production code. They start their life as an executable specification. As the production code emerges, Scenarios take on a role as living documentation and automated tests.

Each Cucumber test is called a scenario, and each scenario contains steps that tell Cucumber what to do.

Gherkin

The keywords Feature, Scenario, Given, When, and Then are the structure, and everything else is documentation. The structure is called Gherkin.

Cucumber features are all about communicating with business users in their language, and it’s important that we don’t force them to sound like robots.

Structure

We start with features, which contain our scenarios and steps. The steps of our scenarios call step definitions that provide the link between the Gherkin fea- tures and the application being built.

This principle, deliberately doing the minimum useful work the tests will let us get away with, might seem lazy, but in fact it’s a discipline. It ensures that we make our tests thorough: if the test doesn’t drive us to write the right thing, then we need a better test.

Step Definitions

Step definitions are the glue that binds your Cucumber tests to the application you’re testing.

A scenario that’s been executed can end up in any of the following states:

• Failed
• Pending
• Undefined
• Skipped
• Passed These states are designed to help indicate the progress that you make as you develop your tests.

Pending Steps

When Cucumber discovers a step definition that’s halfway through being implemented, it marks the step as pending (yellow). Again, the scenario will be stopped, and the rest of the steps will be skipped or marked as undefined.

public class Steps {
@Given("^I have deposited \\$(\\d+) in my account$")
public void iHaveDeposited$InMyAccount(int amount) throws Throwable {
    // Write code here that turns the phrase above into concrete actions
throw new PendingException(); }
}

Step definition recap

The pending status is a bit like those under construction signs you used to see all over the Internet in the 1990s. You can use it as a temporary signpost to your teammates that you’re in the middle of working on something.

Because regular expressions can contain wildcards, this means you have the flexibility to make the Gherkin steps nice and readable, while keeping your Java step definition code clean and free of duplication. • Step definitions provide a mapping from the Gherkin scenarios’ plain- language descriptions of user actions into Java code, which simulates those actions. • Step definitions are registered with Cucumber by using @Given, @When, @Then, or one of the aliases for your spoken language. • Step definitions use regular expressions to declare the steps that they can handle. Because regular expressions can contain wildcards, one step definition can handle several different steps. • A step definition communicates its result to Cucumber by raising, or not raising, an exception.

recap

• Readability should be your number-one goal when writing Gherkin fea- tures. Always try to sit together with a stakeholder when you write your scenarios, or at the very least pass them over for feedback once you’ve written them. Keep fine-tuning the language in your scenarios to make them more readable.
• Use a Background to factor out repeated steps from a feature and to help tell a story.
• Repetitive scenarios can be collapsed into a Scenario Outline.
• Steps can be extended with multiline strings or data tables.
• You can organize features into subfolders, like chapters in a book.
• Tags allow you to mark up scenarios and features so you select particular sets to run or report on.

Sample

compile and run via CLI

javac -cp "jars/*" step_definitions/CheckoutSteps.java
java -cp "jars/*:." cucumber.api.cli.Main -p pretty --snippets camelcase \
                          -g step_definitions features

Line 1 compiles the CheckoutSteps class that we’ve just created. Then line 2 invokes Cucumber. There are two slight additions to Cucumber’s invocation:

1. We’ve added the current directory “.” to the classpath.
2. We’ve added the -g step_definitions command-line argument to tell Cucumber where to look for the step definitions that it will need to “glue” the steps in the feature file to the checkout application (which we haven’t written yet).

feature file

Feature: Is it Friday yet?
  Everybody wants to know when it's Friday

  Scenario: Sunday isn't Friday
    Given today is Sunday
    When I ask whether it's Friday yet
    Then I should be told "Nope"

The first line of this file starts with the keyword Feature: followed by a name. It’s a good idea to use a name similar to the file name.

The second line is a brief description of the feature. Cucumber does not execute this line, it’s just documentation.

The fourth line, Scenario: Sunday is not Friday is a Scenario, which is a concrete example illustrating how the software should behave.

The last three lines starting with Given, When and Then are the steps of our scenario. This is what Cucumber will execute.

Notice how we go from Scenario to Scenario Outline when we start using Examples.

Feature: Is it Friday yet?
  Everybody wants to know when it's Friday

  Scenario Outline: Today is or is not Friday
    Given today is <day>
    When I ask whether it's Friday yet
    Then I should be told <answer>

  Examples:
    | day | answer |
    | "Friday" | "TGIF" |
    | "Sunday" | "Nope" |
    | "anything else!" | "Nope" |

Scenario Outline: Withdraw fixed amount Given I have in my account When I choose to withdraw the fixed amount of Then I should receive cash And the balance of my account should be Examples: | Balance | Withdrawal | Received | Remaining | | $500 | $500 | $500 |$50 |$50 |$450 | | $100 | $100 | $400 | | $200 | $200 | $300 | We indicate placeholders within the scenario outline using angle brackets (<..>) where we want real values to be substituted. The scenario outline itself is useless without an Examples table, which lists rows of values to be substituted for each placeholder.

Doc Strings

Doc strings allow you to specify a larger piece of text than you could fit on a single line. For example, if you need to describe the precise content of an email message, you could do it like this: Scenario: Ban Unscrupulous Users When I behave unscrupulously Then I should receive an email containing: “”” Dear Sir, Your account privileges have been revoked due to your unscrupulous behavior. Sincerely, The Management “”” And my account should be locked Just like a data table, the entire string between the “”” triple quotes is attached to the step above it. The indentation of the opening “”” is not important, although common practice is to indent two spaces from the enclosing step, as we’ve shown. The indentation inside the triple quotes, however, is signifi- cant: imagine the left margin running down from the start of the first “””. If you want to include indentation within your string, you need to indent it within this margin.

TGIF

Thanks God It’s Friday

Data table

Given these Users:
| name | date of birth | 
| Michael Jackson | August 29, 1958 | 
| Elvis | January 8, 1935 | 
| John Lennon | October 9, 1940 |

That’s much clearer. The table starts on the line immediately following the step, and its cells are separated using the pipe character: |. You can line up the pipes using whitespace to make the table look tidy, although Cucumber doesn’t mind whether you do; it will strip out the values in each cell, ignoring the surrounding whitespace.

public class BoardSteps { @Given(“^a board like this:$”) public void aBoardLikeThis(DataTable arg1) throws Throwable { // Write code here that turns the phrase above into concrete actions // For automatic transformation, change DataTable to one of // List, List<List>, List<Map<K,V>> or Map<K,V>. // E,K,V must be a scalar (String, Integer, Date, enum etc) throw new PendingException(); }

BDD

The two main practices in the BDD approach are discovery workshops, which bridge the communication gap between business and IT, and executable specifications.

Background

Background:
Given I have been issued a new card
And I insert the card, entering the correct PIN And I choose "Change PIN" from the menu
Scenario: Change PIN successfully
When I change the PIN to 9876
Then the system should remember my PIN is now 9876
Scenario: Try to change PIN to the same as before
When I try to change the PIN to the original PIN number Then I should see a warning message
And the system should not have changed my PIN

Our refactoring hasn’t changed the behavior of the tests at all: at runtime, the steps in the background are executed at the beginning of each scenario, just as they were before. What we have done is made each individual scenario much easier to read.

Using a Background element isn’t always necessary, but it’s often useful to improve the readability of your features by removing repetitive steps from individual scenarios.

A good ‘background’

• Make your Background section vivid. Use colorful names and try to tell a story, because your readers can keep track of stories much better than they can keep track of dull names like User A, User B, Site 1, and so on. If it’s worth mentioning at all, make it really stand out.
• Keep your scenarios short, and don’t have too many. If the Background is more than three or four steps long, think about using higher-level steps or splitting the feature file in two. You can use a background as a good indicator of when a feature is getting too long: if the new scenarios you want to add don’t fit with the existing background, consider splitting the feature.
• Avoid putting technical details such as clearing queues, starting back- end services, or opening browsers in a background.

Backgrounds are useful for taking Given (and sometimes When) steps that are repeated in each scenario and moving them to a single place. This helps keep your scenarios clear and concise.

Discovery Workshops

Discovery workshops (or Specification workshops) are short and frequent meetings where business and IT meet to gain a common understanding of how the software should behave.

Relationship with TDD

The main difference is that Cucumber operates on a higher abstraction level, closer to the domain and farther away from classes and methods. BDD builds on TDD, while preserving a strong link between the business requirements and the technical solution.

Outside in

This technique is called Outside-in because programmers typically start with the functionality that is closest to the user (the user interface, which is on the outside of the system) and gradually work towards the guts of the system (business logic, persistence, messaging and so on) as they discover more of what needs to be implemented.

Your cucumber features should drive your implementation, not reflect it.

This means Cucumber features should be written before the code implementing the feature.

Notice that we’re just sketching out the interface to the class, rather than adding any implementation to it. This way of working is fundamental to out- side-in development. We try not to think about how the Account is going to work yet but concentrate on what it should be able to do.

Keeping specifications, regression tests and documentation in a single place reduces the overhead of keeping multiple documents in sync - the Cucumber scenarios work as a shared source of truth for business and IT.

While many people focus on the value added by the automated “tests” you get out of BDD, the real value is actually the shared understanding we get at the beginning.

Cucumber is not a tool for testing software. It is a tool for testing people’s understanding of how software (yet to be written) should behave.

The biggest advantage of BDD approach for software development might be that they describe a set of functions that a user expects from a system in a very concrete and direct manner. The sum of these behaviors essentially document a contract with the user/client. If any of the tests fail, this contract is not upheld.

Process

the most important stage of BDD. Three amigos (business persons, developers, testers) get together and identify the expected behavior of our product by discussing examples. We can use feature mapping approach to effectively analyse and elaborate the product behavior.

always make sure that your scenarios are not tightly coupled with your tests. Your BDD scenarios should change only when the requirement changes, not when the the implementation changes (i.e. your BDD scenarios must drive the implementation, not the other way around).

Executable Specification

An Executable Specification is a Definition of Done that you can run as a test. In Behavior Driven Development (BDD), we refer to acceptance criteria as “executable specifications.” Executable Specifications are meant to be clear, unambiguous, written in business terms, and easy to automate. Each acceptance criteria is a concrete example of how a user interacts with the system to achieve some business goal.

The most well-known format for BDD acceptance criteria uses the “Given-When-Then” structure:

Given <some precondition>
When <something happens>
Then <we expect some outcome>

This format is a great way to make sure that we are thinking in terms of the outcomes we want to achieve. After all, the outcomes of an application are where the value lies.

These scenarios are also easy to automate with BDD tools like Cucumber and Specflow.

No silver bullet

“The hardest single part of building a software system is deciding precisely what to build.” We’ve all worked on projects where, because of a misunderstanding, code that we’d worked hard on for several days or more had to be thrown away. Better communication between developers and stakeholders is essential to help avoid this kind of wasted time. One technique that really helps facilitate this communication is the use of concrete examples to illustrate what we want the software to do.

Concrete Examples

By using real-world examples to describe the desired behavior of the system we want to build, we stay grounded in language and terminology that makes sense to our stakeholders: we’re speaking their language.

To illustrate this, let’s imagine you’re building a credit card payment system. One of the requirements is to make sure users can’t enter bad data. Here’s one way of expressing that: Customers should be prevented from entering invalid credit card details. This is an example of what Agile teams often call acceptance criteria or condi- tions of satisfaction.1 We use the word acceptance because they tell us what the system must be able to do in order for our stakeholders to find it acceptable.

The previous requirements statement is useful, but it leaves far too much room for ambiguity and misunderstanding. It lacks precision. What exactly makes a set of details invalid? How exactly should the user be prevented from entering them? We’ve seen too many projects get dragged into the tar pit2 by these kind of worthy but vague statements. Let’s try illustrating this requirement with a concrete example: If a customer enters a credit card number that isn’t exactly 16 digits long, when they try to submit the form, it should be redisplayed with an error message advising them of the correct number of digits.

Can you see how much more specific this second statement is? As a developer implementing this feature, we know almost everything we need to be able to sit down and start working on the code. As a stakeholder, we have a much clearer idea of what the developer is going to build. In fact, a stakeholder reading this might point out that there are certain types of cards that are valid with fewer than 16 digits and give us another example. This is the real power of examples: they stimulate our imagination, enabling us to explore and discover edge cases we might otherwise not have found until much later.

By giving an example to illustrate our requirement, we’ve turned an acceptance criterion into an acceptance test. Now we have something unambiguous that we can use to test the behavior of the system, either manually or by using an automated test script.

Gherkins

dry run

$ java -cp ".:jars/*" cucumber.api.cli.Main -g step_definitions --dry-run features 

The –dry-run switch tells Cucumber to parse the file without executing it. It will tell you if your Gherkin isn’t valid.

Replacing Given/When/Then with Bullets

Some people find Given, When, Then, And, and But a little verbose. There is an additional keyword you can use to start a step: * (an asterisk). We could have written the previous scenario like this: Scenario: Attempt withdrawal using stolen card * I have $100 in my account

• my card is invalid
• I request $50
• my card should not be returned
• I should be told to contact the bank To Cucumber, this is exactly the same scenario. Do you find this version easier to read? Maybe. Did some of the meaning get lost? Maybe. It’s up to you and your team how you want to word things. The only thing that matters is that everybody understands what’s communicated.

CucumberOptions

the @CucumberOptions. One can define the location of features, glue files (step definitions), and formatter plugins inside this Cucumber options.

@CucumberOptions(
        features = "src/test/resources/features",
        glue = {"stepdefs"},
        tags = {"~@Ignore"},
        format = {
                "pretty",
                "html:target/cucumber-reports/cucumber-pretty",
                "json:target/cucumber-reports/CucumberTestReport.json",
                "rerun:target/cucumber-reports/rerun.txt"
        })
public class TestRunner {

Step definitions

Cucumber doesn’t know how to execute your scenarios out-of-the-box. It needs Step Definitions to translate plain text Gherkin steps into actionsthat will interact with the system. When Cucumber executes a Step in a Scenario, it will look for a matching Step Definition to execute.

After

one can implement initial configurations of the project in TestNG’s BeforeClass method. In cucumber’s Before hook, one can implement code to open web browser which is a prerequisite for all scenarios. In Background of each feature, one can implement steps to navigate to web site and/or login to account. In Cucumber’s After hook, one can take a snapshot of failure and close the browser.

tags

Grouping Features, Scenarios, and Step Definitions using Tags Tags is a great way made for Cucumber power users to organize their features and scenarios. In above example, by changing tags = {“~@Ignore”} line totags = {“@UpdateProfile”}, one can choose run only the features and scenarios tagged with @UpdateProfile tag. A Scenario or feature can have as many tags as you like. Just separate them with spaces: @important @maintenance @db @auth

If subfolders are the chapters in your book of features, then tags are the sticky notes you’ve put on pages you want to be able to find easily. You tag a scenario by putting a word prefixed with the @ character on the line before the Scenario keyword, like this: @widgets Scenario: Generate report Given I am logged in

There are three main reasons for tagging scenarios:

• Documentation: You want to use a tag to attach a label to certain scenarios, for example to label them with an ID from a project management tool.
• Filtering: Cucumber allows you to use tags as a filter to pick out specific scenarios to run or report on. You can even have Cucumber fail your test run if a certain tag appears too many times.
• Hooks: Run a block of code whenever a scenario with a particular tag is about to start or has just finished.

config tag

Tags are a great way to organise your features and scenarios. Consider this example:

@billing Feature: Verify billing

@important Scenario: Missing product description Given hello

Scenario: Several products Given hello A feature or scenario or can have as many tags as you like. Just separate them with spaces:

@billing @bicker @annoy Feature: Verify billing Tags can be placed above the following Gherkin elements:

Feature Scenario Scenario Outline Examples It is not possible to place tags above Background or steps (Given, When, Then, And and But).

Cucumber for java 8 lambda

Using Lambda Expressions for Step Definitions Java Step Definitions are written in regular classes which don’t need to extend or implement anything. They can be written either using lambda expressions or method annotations. In the above, we used the method annotations. To use lambda expressions, use cucumber-java8 module instead of cucumber-java module in your pom.xml file.

When you use the cucumber-java8 module, you can write the Step Definitions using lambdas:

package cucumber;

import cucumber.api.java8.En;
 
public class StepDefinitions implements En {
    public StepDefinitions() {
        Given("I have (\\d+) cukes in my belly", (Integer cukes) -> {
            System.out.format("Cukes: %n\n", cukes);
        });
    }
}


package steps;
 
import cucumber.api.java8.En;
 
public class MyStepdefs implements En {
 
    public MyStepdefs() {
       Given("I login as (.*)$",(String name)-> System.out.println(name));
    }
}

Gherkin

Cucumber tests are expressed using a syntax called Gherkin. Gherkin files are plain text and have a .feature extension.

Steps and Step Definitions

Let’s start by clarifying the distinction between a step and a step definition. Each Gherkin scenario is made up of a series of steps, written in plain lan- guage. On its own, a step is just documentation; it needs a step definition to bring it to life. A step definition is a piece of code that says to Cucumber, “If you see a step that looks like this…, then here’s what I want you to do….” When Cucumber tries to execute each step, it looks for a matching step defi- nition to execute. So, how does Cucumber match a step definition to a step?

Creating a Step Definition

If Cucumber sees a step definition with this regular expression, it will execute it when it comes to the first step of our scenario. So, how do we create a step definition?

Step definitions live in ordinary files. To create a step definition in Java, you use a special Cucumber annotation, such as @Given, like this: @Given(“I have \$100 in my Account”) public void iHave$100InMyAccount() throws Throwable { // TODO: code that puts $100 into User’s Account goes here }

Given, When, Then Are the Same

It doesn’t actually matter which of the three methods you use to register a step definition, because Cucumber ignores the keyword when matching a step. Under the hood, all of the annotations are aliases for StepDefAnnotation.

The best way we’ve found to avoid this kind of problem is to pay careful attention to the precise wording in your steps. You could change both steps to be less ambiguous: Given I have deposited $100 in my Account Then the balance of my Account should be $100 By rewording the steps like this, you’ve made them better at communicating exactly what they will do when executed. Learning to spot and remove this kind of ambiguity is something that takes practice. Paying attention to the distinction in wording between two steps like this can also give you hints about concepts that may not be expressed in your code but need to be. It might seem pedantic, but we’ve found that teams who pay this much careful attention to detail write much better software, faster.

Alternation

We can specify a wildcard in a regular expression using a few different approaches. One of the simplest is alternation, where we express different options separated by a pipe character |, like this:

@Given("I have deposited \\$(100|250) in my Account") public void iHaveDeposited$InMyAccount(int amount) {
  // TODO: code goes here
}

This step definition will now match a step with either of the two values 100 or 250 in it, and the number will be captured and passed to the method as an argument. Alternation can be useful if there are a fixed set of values that you want to accept in your step definition, but normally you’ll want something a little looser.

The Dot

The dot is a metacharacter, meaning it has magical powers in a regular expression. Literally, a dot means match any single character. So, we can try this instead:

@Given("I have deposited \\$(...) in my Account") public void iHaveDeposited$InMyAccount(int amount) {
  // TODO: code goes here
}

That will now match a step with any three-figure dollar sum and send the matched amount into the method.

What If I Actually Want to Match a Dot?

Any of the metacharacters like the dot can be escaped by preceding them with a backslash. So, if you wanted to specifically match, say 3.14, you could use “3\.14”. You might have noticed that there’s a backslash in front of the dollar amount in the step definition we’re using. That’s because $ itself is a metacharacter (it’s an anchor, which we’ll explain later), so we need to escape to make it match a normal dollar sign.

Star modifier

The star modifier means any number of times. So, with .* we’re capturing any character, any number of times. Now we’re getting somewhere—this will allow us to capture all those different amounts. But there’s still a problem. The star modifier is a bit of a blunt instrument. Because we’re using it with the dot that matches any character, it will gobble up any text at all up until the phrase in my Account. This is why, in regex terminology, the star modifier is known as a greedy operator. For example, it would happily match this step: Given I have deposited $1 and a cucumber in my Account The amount captured by our regular expression in this case would be 1 and a cucumber. We need to be more specific about the characters we want to match and just capture numbers. Instead of a dot, we can use something else.

Character Classes

Character classes allow you to tell the regular expression engine to match one of a range of characters. You just place all of the characters you would accept inside square brackets:

@Given("I have deposited \\$([01234567890]*) in my Account") public void iHaveDeposited$InMyAccount(int amount) {
  // TODO: code goes here
}
For a continuous range of characters like we have, you can use a hyphen:
@Given("I have deposited \\$([0-9]*) in my Account") public void iHaveDeposited$InMyAccount(int amount) {
  // TODO: code goes here
}

Shorthand Character Classes

For common patterns of characters like [0-9], there are a few shorthand char- acter classes that you can use instead. You may find this just makes your regular expressions more cryptic, but there are only a few to learn. For a digit, you can use \d as a shorthand for [0-9]:

@Given("I have deposited \\$(\\d*) in my Account") public void iHaveDeposited$InMyAccount(int amount) {
  // TODO: code goes here
}

Here are the most useful shorthand character classes: \d stands for digit, or [0-9]. \w stands for word character, specifically [A-Za-z0-9_]. Notice that underscores and digits are included but not hyphens. \s stands for whitespace character, specifically [ \t\r\n]. That means a space, a tab, or a line break. \b stands for word boundary, which is a lot like \s but actually means the opposite of \w. Anything that is not a word character is a word boundary. You can also negate shorthand character classes by capitalizing them, so for example, \D means any character except a digit. Back to matching our amount. It looks like we’re done, but there’s one last problem to fix. Can you see what it is?

question mark

Like the star and the plus, the question mark modifies the character that precedes it, specifying how many times it can be repeated. The question mark modifier means zero or one times; in other words, it makes the preceding character optional. In step definitions, it’s particularly useful for plurals: @Given(“I have (\d+) cucumbers? in my basket”) public void iHaveCucumbersInMyBasket(int number) { // TODO: code goes here }

noncapturing group

@When(“I (?:visit|go to) the homepage”) public void iVisitTheHomepage() { // TODO: code goes here } Notice that we’ve had to prefix the list of alternates with another bit of regular expression magic. The ?: at the start of the group marks it as noncapturing, meaning Cucumber won’t pass it as an argument to our block.

Anchors

The undefined steps start with a ^ and end with a $. These two metacharacters are called anchors, because they’re used to tie down each end of the regular expression to the beginning and end of the string that they match on.

Generally, it’s best to keep your regular expressions as tight as you can so that there’s less chance of two step definitions clashing with each other.

Guides on how to write scenarios

Try to avoid being guided by existing step definitions when you write your scenarios and just write down exactly what you want to happen, in plain English. In fact, try to avoid programmers or testers writing scenarios on their own. Instead, get nontechnical stakeholders or analysts to write the first draft of each scenario from a purely business-focused perspective or ideally in a pair with a programmer to help them share their mental model. With a well- engineered support layer, you can confidently and quickly write new step definitions to match the way the scenario has been expressed.

Imperative Steps

In computer programming, there are two contrasting styles for expressing the instructions you give to a computer to make it do something for you. These styles are called imperative programming and declarative programming.

Imperative programming means using a sequence of commands for the com- puter to perform in a particular order. Java is an example of an imperative language: you write a program as a series of statements that Java runs one at a time, in order. A declarative program tells the computer what it should do without prescribing precisely how to do it. CSS is an example of a declar- ative language: you tell the computer what you want the various elements on a web page to look like, and you leave it to take care of the rest.

Use a Declarative Style Instead

Let’s raise the level of abstraction in this scenario and rewrite it using a more declarative style: Scenario: Redirect user to originally requested page after logging in Given I am an unauthenticated User When I attempt to view some restricted content Then I am shown a login form When I authenticate with valid credentials Then I should be shown the restricted content The beauty of this style is that it is not coupled to any specific implementation of the user interface. This same scenario could apply to a thick-client or mobile application. The words it uses aren’t technical and are instead written in a language (unauthenticated, restricted, credentials) that any stakeholder interested in security should be able to clearly understand. It’s by expressing every scenario at this level of abstraction that you discover your team’s ubiquitous language.

DAMP

However, when you are using examples to drive your code, there is another principle in play that I believe trumps the DRY principle: the examples should tell a good story. They are the docu- mentation narrative that will guide future programmers (including you when you come back to change this code in three months time and you’ve forgotten what it does). In this case, clarity of intent is found in the quality of the narrative, not necessarily in minimizing duplication.

Some people refer to this as the DAMP principle: Descriptive and Meaningful Phrases. When you’re writing examples, readability is paramount, and DAMP trumps DRY.

We consider fixture data to be an antipattern. We much prefer using Test Data Builders, on page 104, where the relevant data is created within the test itself, rather than being buried away in a big tangled set of fixture data.

We find that teams that have a single humongous build also tend to have an architecture that could best be described as a big ball of mud. Because all of the behavior in the system is implemented in one place, all the tests have to live in one place, too, and have to all be run together as one big lump. This is a classic ailment of long-lived applications, which have grown organically without obvious interfaces between their subsystems.

Defect Prevention

Toyota’s counterintuitive but hugely successful policy of stopping the line works because it’s part of a wider process, known as defect prevention, that focuses on continuously improving the manufacturing system. Without this wider process, stop the line itself would have very little effect. There are four steps to this process:

• Detect the abnormality.
• Stop what you’re doing.
• Fix or correct the immediate problem.
• Investigate the root cause and install a countermeasure. This fourth step is crucial because it seizes the opportunity offered by the problem at hand to understand something more fundamental about your process. It also means that fixing things becomes a habit, rather than some- thing you put off to do someday later when you’re not in such a hurry.

Cucumber might just seem like a testing tool, but at its heart it’s really a collaboration tool. If you make a genuine effort to write features that work as documentation for the nontechnical stakeholders on your team, you’ll find you are forced to talk with them about details that you might never have otherwise made the time to talk about. Those conversations reveal insights about their understanding of the problem, insights that will help you build a much better solution than you would have otherwise. This is Cucumber’s big secret: the tests and documentation are just a happy side effect; the real value lies in the knowledge you discover during those conversations.

Reference

• https://medium.com/agile-vision/cucumber-bdd-part-2-creating-a-sample-java-project-with-cucumber-testng-and-maven-127a1053c180
• https://codoid.com/cucumber-lambda-expressions/

• 2024 10
• 2023 98
• 2022 51
• 2021 19
• 2020 25
• 2019 7
• 2018 39
• 2017 38
• 2016 50