How Cucumber Open Source Maintainers Do Mob Programming
infoq.com
infoq.com
1: “All the brilliant people, working on the same thing, at the same time, in the same space, and at the same computer.“
That information can inform choices that would eventually lead to more productivity overall.
This was perhaps 4 hours per week though. I'm sceptical about this being a good way to do things all the time.
---
Why we tried it
When asked to implement a rather big task, like an epic, you’re often in a state where you have a pretty good picture of what needs to be done on high level, but on a lower level it can be very fluffy and unclear. Fluffy enough to stand in the way of being able to ”slice the cake” in nice, independent, deliverable user stories. Fluffy enough to give us problems if our aim is to have a structured, ordinary sprint backlog prepared, and to burn that backlog down continuously by developing small software increments for a couple of weeks. You know you’re in that fluffy state when:
- Someone asks where a good place to start this epic is and all possible ways you can think of are either intertwined and far from independent steps or just one big mega user story
- You get a urge to just start coding, hack away for a while and see where you end up
- You may even wish that you, for a while at least, could forget everything related to user stories, epics, backlogs and burn downs and just do some Programming, Motherfucker http://programming-motherfucker.com/
---
Now, if this technique can supposedly solve that critical problem -- and it is critical; I spend >N% of my time in that sate -- we should give it the benefit of the doubt and just try it.
It sounds like the point is to spend a couple hours in an environment where forward progress is always being made every minute, yet freedom has been completely removed.
I think I'd volunteer for that, to be honest. It's so nice working from a designer's mockup rather than trying to design + build the whole app simultaneously. That same feeling might apply here.
It's kind of compelling. But only if everyone actually wants to do it.
Think of how much time we've all wasted fiddling around with design, moving property lists around, exploring new approaches, or throwing in an hour of metaprogramming only to find out it reduced our line count from 150 to 100 and made it quite a lot harder to read.
If you tried to pull any of that during one of these sessions, you'd get called out immediately.
Oh yeah: http://hackthesystem.com/blog/why-i-hired-a-girl-on-craigsli...
You know, this really should be a thing. I wonder if devs would pay for this? I'd give someone $20/hr to keep me on track. But they'd need to know enough about programming not to be annoying or blatantly mistaken.
It's not a panacea, but it manages to do a lot of various things that might take a long time and do them immediately.
That said I haven't made up my mind yet if it is good and I just don't get it yet or if it is a mostly a waste of time.
The problem with test suites is that, as they grow and age, it becomes harder and harder to understand why tests are testing what they test. When a years old test fails because 5 is not 7, you cannot really fix it unless you understand why it was supposed to equal 7 in the first place.
Cucumber is a way to describe requirements at a higher level of abstraction. They provide rationale on top of mere assertions of behavior. This is worth the small overhead of writing step definitions.
I guess you can get the same by heavily commenting your tests. But you cannot enforce this easily in a team.
Our biz people can't write useful requirements so I doubt they can write meaningful Cucumber scripts either.
I think that they add way too much complexity. It doesn't make sense to try to write technical software tests at such a high level of abstraction.
When you try to test something at a really high level along the lines of "As a user, when I click on X, I want Y to happen" the low level technical ramifications of this can be enormous.
There is a huge amount of underlying complexity which the one-line sentence simply cannot capture and which is prone to change and needs to be tested separately... Probably not in a way that a non-technical manager would understand unfortunately.
Ultimately the tests are not granular enough to be useful as tests for developers and they have too much overhead to be useful as documentation for non managers.
With a DSL-driven BDD framework (like rspec) you get autocomplete and debugging and every other language feature without really losing any of the descriptiveness.
With cucumber you get lots of pain in both those areas, without anything that feels like an improvement along another metric.
Phase 1
Non-technical and semi-technical business analysts write scenarios as acceptance criteria for the requirements.
They are still so high level that the devs need to re-write or refactor the majority of them to be able to get any sort of re-use out of them.
Phase 2
Writing scenarios is largely seen as a time sink and the test coverage is falling behind. This is then changes so that the BAs write a headline scenario and some high-level bullet points (higher level than they were doing already) which are then fleshed out by devs.
Devs re-write statements in ways that aren't very good english ('When I log in as a "Tim_test5"') and scenarios are no longer good to show to the customer.
Phase 3
Test writing is still slow, so BAs and testers start writing and performing manual tests to close the user stories. Step 'library' and feature files are building up but still only a relative handful of tests are automated.
So yeah, in an ideal world they would be perfect, but I would recommend the following:
* Don't include BDD in your 'definition of done'. You will never close anything.
* Only write BDD for things that are stable - some changes can mean that tests need to be updated, split or take more arguments. Syncing up changes to statements in feature files is extra overhead.
* Deciding on wording to reflect business meaning of a statement and technical meaning of a statement is harder than you think. Factor in time for this.
* If your team haven't used BDD before, create some central resource with statements in that can be used by non-technical users to build up scenarios lego-style. If what they need isn't there, then it can be added. This is especially true when a set of actions is easily abstracted to a single business action ("I send the request" or something which takes many clicks and form filling).
Upon submitting/editing it would create a ticket with the story. We also ended up having it create a branch once it was scheduled by product so engineers could git checkout storyXXX and see where the cucumber steps went yellow.
There is a pretty cool SaaS product that does this now more or less that I’ve only gotten to play with http://www.simian.io/
This is the part I could never buy into either. You cannot escape that writing tests is the same thing as programming (you need to break the problem down into steps, formalise what you want to check, use abstractions) so non-programmers aren't good at writing tests without rigorous training. Non-programmers tend to need a lot of help even describing what they want in plain English as well because they just aren't used to thinking like programmers. I've worked with non-technical people for years who still don't understand that "it's not working" isn't enough information to go on.
As for overhead, it might make sense if you're working on one project in a single language for a long time but the setup and configuration overhead has been significant when I've tried BDD tests.
I'd rather just use descriptive function names in tests as then you can take advantage of autocompletion, automated refactoring, jump to definition shortcuts, static checking, language features etc.