CukenFest 2019

I’m just back home from an inspirational couple of days at CukenFest, time for a quick summary while things are still fresh in my head.

The Venue

The conference was held on the second floor at the wonderful Wallacespace venue in the Spitalfields area of London. The canteen on the top floor provided breakfast and lunch for both days and was open for drinks and snacks if you needed to get away from the conference for a bit.

Being located in Spitalfields this was a great area to go for a little strole in the breaks for some fresh air or greater selection of food at the Spitalfields market.

Day 1

The format of the first day was a single track of 15 minute talks with 30 minute keynotes at the start and end, facilitated by Seb Rose from Cucumber.

In contrast to Oslo Elm Day where I thought the short talk format was a little too restrictive it seemed to work really well here, some presenters might have rushed a little towards the end but on the whole the talks felt well paced.

The opening keynote was Jamie Knight and Mike Southgate talking about working on their fraud protection project. A cool reminder that valuable solutions don’t have to be large complex solutions, with their entire codebase having less code than a competitors website.

This talk gave me one of my favourite thoughts for the day

This resonated with me as it pokes at something that’s been bugging me on my current project, maybe it will be the kick in the ass I need to take some initiative to push things in the right direction.

Another quote that stuck with me from the day was Robert Meaney who, during his talk about how to get the “Oh Shite” moment to happen much earlier in the developement lifecycle stated

Testing is not a solution to a quality problem.

I read into this that if you are experiencing quality problems on a project automating/testing incorrect understanding isn’t going to achieve much, there are other communication issues that need to be addressed.

One of the more technically interesting talks of the day was Ciaran McNulty’s talk on Doodle Driven Development. If I understood correctly, while requirements were being defined in Gherkin already, when discussing how to implement the solution developers were using drawings of a state machine model to further understand the behaviour. This lead to the realisation that if the diagrams are useful for understanding the system then perhaps diagrams could be used when communicating with the business too. By modelling these diagrams in GraphVis they were able to write a primitive parser that allows the diagrams to be automatable as tests, this was also a good reminder that a valuable test doesn’t need to be shoe-horned into an existing test framework as long as it runs automatically and is possible to maintain. Slides from this talk are up on Slideshare.

The “Cucumber in a microservice environment” talk was interesting, if only as a sanity check of how we are doing tests on my current project as the diagrams seem to match our architecture fairly well.

The closing keynote from Alexandra Schladebeck was great. Her experiences resonate very well with stories I’ve heard from a large norwegian bank that recently restructred development into “tribes” that have multiple types of mangers, including financial controllers, but no testers, it also resonated with some of my own thoughts on the value testers can provide to me as a developer by providing insight from a testing perspective to identify gaps in my test coverage or areas where tests have less value as they test the same thing.

Another interesting point from that talk was that test code written by testers learning to code tends to use a lot of static methods, and that is ok. The fun thing here is that this reflects the direction that I feel development is going in of preferring a more functional style to writing code, especially once you break away from the big enterprisey tools and frameworks.

Day 2

The second day of the conference was 6 workshops, mostly in a single room, with three other rooms made available for open space discussions. The day started off with Steve Tooke facilitating a session to get open space proposals together which resulted in the following schedule.

I attended the sessions on “Gherkin statement curation” which blead nicely into the “How to maintain a large suite of tests and re-usable steps?” session. While there were differing opinions it was a good discussion.

One of the issues that was most disagreement on was how to manage “given"s. Some prefer an all powerful single given statement that is able to hide a lot of complexity, versus small reusable steps and-ed together. Personally I prefer the former to reduce noise in the test. One interesting comprimise could be one statement for domain setup (Given I have an X in a state Y) followed by a statement for application setup (And I am on the Z page/screen), although this could again be seen as leaking technical details of the “When” steps that could or should be implicit.

There was however strong agreement in the group that using tags and before hooks to hide prerequisites is an antipattern. That needs to be communicated though “given” statements or background.

Then I went to the Event storming and example mapping workshop. This could have been a little better and needed a lot more time. Personally I think it would have been even better with more, slightly smaller groups, but it was still interesting to go through the motions of techniques I’ve only previously read about.

Unfortunately I missed the afternoon session due to general exhaustion, I think the last few months finally caught up with me once I had a litte time away from the kids at home. This was a huge shame as there were multiple open space sessions and workshops that sounded interesting.


In addition to everything I dumped above I’ve got a page full of notes of thoughts I’ve had during the conference that are more directly related to my current project that could be interesting to keep in mind when I get back to work tomorrow. While I’m not sure that I have the strength or motivation to advocate for doing BDD “properly” instead of just automating some tests with Cucumber, I’ve been reminded of various principals and ideas that can still improve the quality of what we are doing. Definitely worth the trip.