The Cucumber Book: Behaviour-Driven Development for Testers and Developers (Pragmatic Programmers)
Matt Wynne
Language: English
Pages: 336
ISBN: 1934356808
Format: PDF / Kindle (mobi) / ePub
Your customers want rock-solid, bug-free software that does exactly what they expect it to do. Yet they can't always articulate their ideas clearly enough for you to turn them into code. The Cucumber Book dives straight into the core of the problem: communication between people. Cucumber saves the day; it's a testing, communication, and requirements tool - all rolled into one.
We'll show you how to express your customers' wild ideas as a set of clear, executable specifications that everyone on the team can read. You'll learn how to feed those examples into Cucumber and let it guide your development. You'll build just the right code to keep your customers happy, and not a line more.
The first part of the book teaches you how to use the core features of Cucumber. You'll learn how to use Cucumber's Gherkin DSL to describe-- in plain language - the behavior your customers want from the system. You'll learn how to write Ruby code that interprets those plain language specifications and checks them against your application. In Part 2, you'll consolidate the knowledge you just gained with a worked example.
Although it was born in the Ruby community, you can use Cucumber to test almost any system, from a simple shell script or a Perl script, to enterprise PHP or a Java web application. In Part 3, you'll find a selection of recipes for some of the most common situations you'll encounter using Cucumber in the wild. You'll learn how to test Ajax-heavy web applications with Capybara and Selenium, REST web services, Ruby on Rails applications, command-line applications, legacy applications and lots more!
Written by the creator of Cucumber and one of its most experienced users and contributors, The Cucumber Book is an authoritative guide that will give you and your team all the knowledge you need to start using Cucumber with confidence.
What You Need:
Windows, Mac OS X (with XCode) or Linux
Ruby 1.9.2 and upwards
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. When we talk in terms of these examples, they can really imagine themselves using the system, and that means they can start to give us useful feedback and ideas before a line of code has been written. To illustrate this,
reading each individual scenario, you can focus on what is unique and important about that scenario. To show you what we mean, let’s take an existing scenario that uses only the basic Gherkin Scenario element and improve its readability by refactoring it to use a Background. Here’s our feature before the refactoring starts: Feature: Change PIN Customers being issued new cards are supplied with a Personal Identification Number (PIN) that is randomly generated by the system.
of data, making it hard to read the scenario as a whole. You can also easily create brittle scenarios, where the slightest change to the system causes the scenario to fail because it’s behaving slightly differently than the way it was described in the doc string. OK, we’ve covered the more advanced features of Gherkin you can use to express your business requirements. The last thing we want to talk about in this chapter is keeping things organized. 5.6 Staying Organized with Tags and
dispensed And the balance of my account should be $80 1 scenario (1 passed) 4 steps (4 passed) 0m0.176s Phew! We’ve managed to convert our tests to run against a web interface, and all we needed to do was change the way our World module’s methods were implemented. If we wanted, we could set up our tests to switch between the two modules, giving us fast tests that go directly to the domain model and slower, more thorough tests that go right through the user interface.
new feature in mind, modify those scenarios or write new ones to specify the desired new behavior. Run through the scenarios with your team’s stakeholder representative to check that you’re about to build the right thing. Correct the scenarios with them if necessary. Run the scenarios. If more than one fails, pick one, and examine the code you’ll need to change to make it pass. Write any extra characterization tests you need to give you the confidence to change that code. Change the