I had time for a quick chat with Joseph Wilk to talk about Cucumber and BDD!
MC: 
Thanks very much for taking the time to chat - can you tell us a bit about yourself, and what you do?
JW: I've always been playing around with the internet technologies from a young age, my first jobs were working with designers so I got a lot of early insight into the creative side of building sites. I then went and put myself through a formal MEng in computing, jumped into a J2EE job and then promptly ran away to Python and Ruby.
After playing with Python and Ruby the community and testing culture around Ruby made it my favourite choice. I now spend my time working for a small webshop called eShopworks. I'm currently working on a project building a lite Ruby CMS and I also spend a disproportionate amount of time working on Cucumber.
MC: During that time, I guess you've seen the role of testing and the testing department change quite significantly?
JW: Very much so. I spent some time as the head of testing for a big digital agency dealing with clients like Financial Times and Guinness. I was the head as I was the only member of the test team! Nothing was automated, passing around huge word/excel specification documents was the norm. Little value was seen in testing from the business side. I've also seen testing from the small business side where people did not do any testing and the client was expected to do it for them. Again testing was seen as a cost they could not afford.
I think as the market got more competitive after the .com bubble burst the business folk started to see the advantages they could gain from having a testing strategy.
And the tool set certainly has as come a long way, providing lots of choice for different contexts.
MC: Changes in tools and development methodologies have shifted testing to a much more central role - can you tell us a bit about Cucumber, and how it fits into BDD development?
Haha, you could probably write an entire book on that question... a few sentences will be fine :D
JW: :)
Cucumber is a tool that focuses on filling the communication gap between customers and developers/testers. It allows non-technical people to write/edit/read plain text specifications that are executed as tests. It brings the customers domain language as close as possible to the developer.
As a tool to support BDD Cucumber allows us to work outside-in, focusing on the value to the customer of a feature. Using that value to drive through the layers of the application keeping us focused on delivering the minimal marketable feature.
MC: As a tool that focuses on using a language that the business understands, how does this fit in with the development practice of red/green/refactor? Presumably, you don't have a business owner with you when coding... Where do you draw the line between your cucumber specs and maybe more technical specs that you might write in RSpec?
JW: Very good question.
In Cucumber we dont tend to refer to them as specs, we like to call them scenarios, examples of behaviour.
I think its important to remember that Cucumber is a tool that fits many different usages and contexts. I had an interesting conversation with David Black about writing cucumber instead of specs! There is no one right way.
Cucumber scenarios focus on trying to be as close as possible to how a real user would interact with the system. The customer provides us with a definition of done through these scenarios for a feature.
We start with the same yellow->red->green cycle with Cucumber but its a much bigger cycle. We drop down to the faster red/green/refactor specs when we need to think about implementation details. Cucumber features tend to drive us to the destination but they do not tell us how to get there. Specs help us drive out these implementation details and lower level behaviour. In drawing the line between specs and Features, I often ask myself If I speak to the customer and ask them about this detail what would they say, would they see any value in it.
Since Cucumber features are high level they provide the ability to do some serious refactorings without changes. While the spec levels often requires changes for big refactoring. We wrote lots of Cucumber features for Cucumber before we undertook a big refactor of the internals to give us confidences from the outside of the system everything still worked.
Sorry that was a little long, really interesting question.
MC: Really interesting answer too :) Thanks!
That's great - thanks for those answers, I think we're out of time now:/ Many thanks again for taking the time to chat!
JW: No problem :)
See the interviews category for more.
