Who This Book Is For
Cucumber is designed to help build bridges between the technical and nontechnical members of a software team, and we’ve tried to consider both of those readers. The majority of the book is written to the technical reader, someone who is interested in test automation and already has some programming skill. However, several of the chapters—especially in the first part of the book where we explain how to write specifications—are written with the nontechnical reader very much in mind. Specifically, those chapters are:
- Chapter 1, Why Cucumber?
- Chapter 3, Gherkin Basics
- Chapter 5, Expressive Scenarios
- Chapter 6, When Cucumbers Go Bad
- Chapter 13, Adding Tests to a Legacy Application
As the book develops, we’ll look at more complex testing situations, and the level of technical know-how required to read the chapters will increase. We’ve tried to make this buildup as gradual as possible so that if you’re only just beginning your journey into test automation, you should be able to follow along and learn as we go.
You Don’t Need to Know Ruby, But It Helps
Ruby[2] is an open source programming language that can be installed and run on all major operating systems. The original—and still most popular—version of Cucumber is written in Ruby, and this book is about that version.
That doesn’t mean the system you’re testing has to be written in Ruby. One of Ruby’s many strengths is how good it is at talking to other languages and platforms, and we’ll show you how to use Ruby tools to test web-based systems that could be written in any language.
To follow along with the coding examples in the technical chapters, it will help if you know a little Ruby. Ruby is an easy language to learn, and the Ruby examples we’ll use are deliberately simple. To get the best out of this book, we suggest that Ruby novices accompany it with a copy of Programming Ruby 1.9 & 2.0 (4th edition) [FH13].
It’s OK if You’re Not Test-Driven
We’ve had our greatest success with Cucumber as part of an outside-in approach, starting with a failing Cucumber test and using that to drive our development work on the application code. As developers, this way of working helps us stay honest and avoid the temptation to build in functionality that nobody asked us for, just in case it might be needed one day in the future.
Cucumber is a tool that facilitates this way of working, but it doesn’t force it on you. Some teams use Cucumber to automate tests for the work that developers have already done. This can often be a first step toward adopting an outside-in approach, as Cucumber’s readable tests start to attract the attention of the team’s nontechnical stakeholders, drawing them into the process. Even if you’re using Cucumber to write tests against existing code, you’ll still get a great deal of benefit from Cucumber over alternatives like QTP and Selenium IDE, and we think you’ll still get a lot out of this book. We’re not here to preach to you about process, but we will share our insights about what has worked for us and why.