Today is a big day for Cucumber.
6099 days since the project was first started, 4158 days since we formed Cucumber Ltd, and 2004 days since SmartBear acquired Cucumber Ltd we have entered a new and exciting phase: Cucumber is back in community ownership.
One of the goals the Cucumber team have set ourselves this year is to increase the number of recent, regular contributors who are non-white or non-male from 0 to 2. This post describes why we want to do this, what we’ve learned so far about the systemic barriers that keep the community of people who contribute to open source so utterly imbalanced, and outlines how we’ve started tackling the problem in our own project.
Previously, we extracted our a simple implementation of the screenplay pattern from some existing Cucumber automation code, turning this:
Given('{word} has created an account', function (name) {
this.createAccount({ name })
})
…into this:
Given('{actor} has created an account',
actor => actor.attemptsTo(CreateAccount.forThemselves)
)
We’re going to continue this refactoring, looking at how we can compose granular interactions into tasks that model higher-level concepts in our problem domain.
In the previous post in this series, we explored the need for a new kind of pattern for organising our test automation code.
Now we’re going to work with this little codebase to refactor it towards the Screenplay pattern. By taking the existing code and shifting it, step-by-step, towards the pattern, my hope is that you’ll see how you could do this to your own code, should the fancy take you.
In the first post in this series we introduced the concept of the Screenplay pattern and busted a couple of popular myths about it. Now it's time to start digging into some code to give us a real example to demonstrate the pattern on.
The problem with writing this kind of tutorial, always, is finding the right balance between an example that's so complicated it gets in the way of your understanding the thing we're actually trying to learn about, and one that's so simplistic that the need for any kind of software design seems superfluous. If you'll forgive me, we'll err towards the simplistic here, and I'll trust that you've seen enough complex code in the wild to recognise the need for some design work.
Once you've decided to invest in test automation, sooner or later you'll begin to realise that you need to care about the maintainability of that test automation code just as much as you do about the implementation code itself.
For acceptance tests this problem is particularly acute: driving the application from its outside edges involves connecting to APIs, databases, web UIs etc., and this code can quickly get out of hand. Having tried several different approaches myself over the years, I've come to believe that the Screenplay pattern is the best technique we have today.
But it doesn't get the attention it deserves.
We recently ran a survey as part of the work to bring Cucumber into the SmartBear and HipTest family. It was a quick sample (189 responses collected in under a week) rather than in-depth research, but it yielded a couple of interesting indicators that I want to share.
The team at Cucumber are a special bunch.
Looking back on the first quarter since we were acquired by SmartBear, we took a day out together to reflect on that special-ness. We wanted to try and distill our culture so that we can be deliberate in protecting, celebrating, and spreading it as we integrate into the wider organisation.
This was originally posted on Matt's personal blog.
Barbara is a business analyst.
Until recently, Barbara hated BDD.
I don't know if anyone's counting, but the human race must be creating millions of lines of code every day. It seems to me it would be useful to think about how we judge the value of that code.
I'll run through some of the common answers out there to this question and offer a couple of my own. I've presented them in a rough priority order, starting with the most fundamental, but ending with perhaps the most important.