Matt Wynne

+ Follow
since Feb 17, 2012
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Matt Wynne

Congratulations guys.

Thanks for having us, it was nice to meet you all. If you need any specific help with Cucumber, don't forget there's a dedicated forum over at

12 years ago
Hi Dan,

Cucumber is really just the glue that binds your business-readable specifications to the code in the step definitions that run those specifications. What you put in those step definitions is up to you, and depends on the kind of app you're testing. Cucumber grew up in and around the Rails community, but it's widely used outside of Rails.

We tried to keep the book largely Rails-free. The main worked example doesn't use Rails at all. We've also got a chapter on testing REST APIs (which could be in any language) using the HttParty ruby library to automate the REST API via HTTP, which I think you'd find useful. The best Ruby library for automating web apps is Capybara, and although the chapter on Capybara does use a Rails app as the example, we clearly show how to use it for other kinds of web servers too.

Does that help?
12 years ago
Hi Marty,

I regularly get involved with teams who are beginning a new project and want to make BDD-style collaboration a core part of their working practices. With a couple of days' training with the right person you can set the project out on a much better trajectory.

If it isn't possible to have me come to your workplace and convince people personally. there are loads of great success stories in Gojko Adzic's book, 'Specification by example'.
12 years ago
Hi Roger,

Have you tried putting the transforms.rb file into features/support? That folder is loaded automatically by Cucumber (before your step defs are loaded) so you shouldn't need to require any files in there explicitly.

There's plenty of info on using transforms in our book ;)
12 years ago
Hi Sujoy,

Cucumber and JBehave are designed to solve the same problem: writing automated tests in a way that they feel approachable to non-technical project stakeholders.

I've never used JBehave, but my understanding is that where Cucumber differs from JBehave is in how specifications are written. They both use plain-text files, but Cucumber uses the Gherkin syntax for its feature files, which is getting quite wide adoption, with tools like being written to publish feature files, for example. There are also tools to run Gherkin tests in various different languages such as SpecFlow for C#.

I don't know about the relative merits of the two tools, so I can't comment on that I'm afraid.

To be honest, I'd say that the main thing is not which tool you use, but how you use it:
- are you having regular sessions with the non-technical team members to review the scenarios you're working on?
- does everyone on the team have easy access to the scenarios?
- does everyone on the team feel a sense of shared ownership over the scenarios?

If you've achieved that with JBehave, I'd say you're doing just fine.
12 years ago
Hi Ronald,

Yes, I've seen people use a Cucumber plugin with Netbeans, though I've never used it myself. If you use Cucumber-JVM[1], you can also use the JUnit interface to run the tests just as you would for a normal unit test suite.

12 years ago
Hi Fredrik,

We tried out best to make the book friendly to someone who didn't know much Ruby at all, but the feedback we've had is that we did set the bar a little bit high. We obviously didn't have time to teach Ruby as well as Cucumber, so we did have to make some assumptions about what the reader would be able to learn for themselves about the language outside of the book. The examples are pretty gentle, but you'll probably want a copy of something like Brian Marick's Everyday Scripting With Ruby[1] by your side as you follow along with the examples.

12 years ago
Hi Rob,

You don't say what it is that you normally do, but we've certainly aimed several (especially early on) chapter to non-technical readers. Cucumber's purpose is to bridge the gap between developers and non-technical stakeholders, and we wanted those readers to get something out of the book too. If you're interested in learning some new techniques for analysing and understanding requirements, I think the early chapters in the book will be helpful. You could also try Gojko Adzic's excellent book, Specification by Example:
12 years ago
Hi Venkat,

SpecFlow is essentially the .NET port of Cucumber. If your team are happiest writing their step definitions in C#, I would stick with SpecFlow.
12 years ago
Yes, you should be able to follow along with the examples in the book using RubyMine no problem.
12 years ago
Hi Dan,

Cucumber and RSpec are complimentary tools. You use Cucumber to write high-level end-to-end tests that you can share with project stakeholders, and RSpec to write microtests for individual classes and modules. The RSpec Book explains the process of moving between these two levels of tests very well:
12 years ago
We don't specify an IDE in the book. You can follow along with a very simple text editor. In the appendix, we list out a few different free IDEs and editors that you can use depending on your operating system.

Why do you ask?
12 years ago
Hi Rogerio,

Yes, it is possible. The way to do it is to specify concrete examples of scenarios that the system will find itself in under stress. For example:

Given 1000 users are hitting the homepage simultaneously
When I request the homepage
Then I should get a response within 2ms


Given there are 100,000 users registered on the system
When I create a new account
Then I should be taken to my dashboard within 5ms

Talking through these kinds of scenarios with your stakeholders will help you to understand where the boundary is for what they consider to be acceptable performance. Now you have agreement about this, the next step is to work out how to automate these scenario, by calling your load testing tool of choice from the Cucumber step definitions.

The key thing is to have Cucumber delegate to the stress testing tool, rather than the other way around. A common mistake people make is to simply point JMeter at existing Cucumber scenarios, but this doesn't give you the benefit of having the parameters of the test documented in a readable Cucumber scenario.

These are not normal kinds of Cucumber tests. You would need to run these against an environment that's representative of your production hardware, whereas normal behaviour scenarios could be run against any environment. It's useful to create these scenarios early on during the project and run them against every build so they become constraints within which the project must proceed.
12 years ago
Hi folks!

Could I politely ask that if you're planning to buy the book, please buy it from the publisher's website rather than Amazon? As authors, we get a much greater royalty from the sale if it's made directly through the publisher.

Looking forward to your questions.

12 years ago