Transcripted Summary
In this chapter we've been focusing on Cucumber.
We've done all this talking about BDD and Gherkin, but you might be wondering what is Cucumber and how does it tie into all of this?
Cucumber is a tool that supports BDD and is used to execute Gherkin statements.
It works in a few steps.
Cucumber reads each line of a Gherkin document
It validates that the statements conform to Gherkin syntax
Then it maps each Gherkin statement to some predefined logic. This is code that the automation engineer would have written
Finally, it executes that logic
Pretty simple, right?
This chapter and the remaining ones will be focused on understanding Cucumber, setting up a project that allows us to leverage Cucumber, and getting our hands dirty with creating our own Cucumber-based automation project.
Here is a very high level of view of the role Cucumber plays in test automation.
Cucumber takes the already documented system requirements in the form of Gherkin, does some magic with it which results in tests being automated on various devices and environments.
In future chapters, we'll be tweaking this diagram a bit to show how the Cucumber magic really works to achieve test automation.
# Cumber Pros and Cons
Let's talk briefly about some of the pros and cons of Cucumber.
The first benefit, which is also an extension from BDD, is tests are understood by the entire team.
After following good BDD and Gherkin practices, tests should be easily understood by each member of the project team.
Another benefit is Cucumber allows for continued collaboration and increases the visibility among the entire team.
If tests are utilizing the same documentation that was created when the project was starting, all members of the team can work together to ensure the current behavior and features are being tested.
Cucumber also allows for a test to be refactored easily without changing the actual Gherkin statements.
This is done by updating the underlying code.
As for the cons, with Cucumber you get extra layers of abstraction, and this can add time and effort to create and maintain a test automation project, especially for team members not familiar with Gherkin and Cucumber.
The use of Cucumber can lead to frustration. If not used with correct BDD and Gherkin and practices, the resulting automation project will be harder to understand and maintain.
Lastly, people tend to adopt tools over processes.
So, if Cucumber is implemented as such without regard for the foundation provided by a BDD and sound Gherkin statements, the entire team can come to hate Cucumber and BDD as a whole and end up wasting money and resources trying to implement it as a standalone tool.
# So, the question really is, is BDD and Cucumber right for you?
There are a lot of benefits of BDD and Cucumber, but at the same time it's not always the best choice for a project or a team.
The first point to reiterate is don't use Cucumber only as an automation tool.
You will not get the most value from it. Another point to note, it's best to start out a project knowing the tool within processes you will be using. You may face some friction from a team if Cucumbers introduced halfway through a project, especially if the team is unfamiliar with it.
So, it's best to go into a project knowing that you'll be using it rather than decide halfway through that you want to switch to a BDD approach.
That brings me to another point.
# Is your team ready to take on a BDD approach to software development?
Do you have persons versed at BDD and Cucumber, or resources to train your team?
Do you have the time to train your team?
All of these questions are important to answer before taking on BDD or any new process.
And finally, will your team actually benefit from BDD and Cucumber?
Cucumber may not be as beneficial for a very short project or for a project with 2 or 2 people.
It also may not be very useful in a startup environment where there aren't distinguished roles like project manager, developer, or tester, but rather these roles and responsibilities are melded together with everyone being a little bit of each.
If after considering these with your team, you believe you want to try out Cucumber and BDD, then great.
Let's get started.
# Course Prerequisites
Before we begin, I want to outline some prerequisites for the rest of the course.
Knowledge of JavaScript.
While not completely mandatory, it will help to know the basics of JavaScript to go through the following chapters pretty easily.
Java, NodeJS and npm are mandatory for being able to run the test automation.
These can be pretty easily installed for any OS by following the instructions on their respective sites.
For Java, you can head to oracle.com.
Click on the downloads link here, scroll down, and select Java JDK for developers, and this will take you to a screen where you can download different versions of Java.
I'd recommend selecting the LTS version, which as of right now is 11.0.4. Click the download link here and based on your operating system, select the right file to download.
For Node and npm, those both come packaged together.
So, once you head to nodejs.org, you can install the LTS version of Node for your operating system and that will come with npm as well.
Once those are installed, you can check that they're on your system path by running the following commands:
java -version
You should see something like this come up in your terminal.
And you can do something similar for Node and npm.
Just type:
node -v
npm -v
If successfully installed, you should see the version numbers of both.
It would also be beneficial to have some prior knowledge of WebDriverIO.
If you aren't familiar with it, don't worry too much. I'll explain as I go along.
WebDriver is really another tool that allows us to interact with a browser and carry out actions as a user would.
Knowing how to create and interpret regular expressions will also be important moving forward.
And finally, you need a text editor to actually create your test automation project.
I'll be using VSCode, but feel free to use whichever one you're comfortable with.
