The monthly dose for BDD addicts… In February #bdd, #specflow and #cucumber stories from Kent Back, Martin Fowler, David Heinemeier Hansson, Bertil Muth, Steve Tooke, Matt Wynne & me.
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the January issue?)
Dear BDD Addicts,
This month seems to have a special topic: the relation of BDD and TDD. It hasn’t been planned like that, I have just stumbled across this topic this month. I think this is a topic that you have to come back to again and again. For a long time I have thought that there is a definite answer, but the more I learn and practice it the more I think that this should be rather a continuous learning, a continuous discovery. And this is all right like that.
Do you want to join this discussion? Do you want to kick-off another one? Send a mail to bddaddict@specsolutions.eu with your topic suggestion or interesting posts, so that I can share it with other addicts.
So let’s dive in to TDD/BDD and take our monthly dose…
[Video:TDD] We deserve to feel confident
Before challenging the relation of BDD and TDD, I think it makes sense to clear some things up regarding TDD. You have probably heard about TDD. What have you heard? The tdd-loop? Unit testing? Testing frameworks? Mocking? Have you realized already that there are multiple TDD-s? Different flavors of that? You can meet multiple approaches to find the “true TDD”, but I don’t think there is one. Nothing proves this better than the discussion moderated by David Heinemeier Hansson with Kent Back and Martin Fowler. (30 minutes)
Is TDD dead? (Kent Back, @KentBeck; Martin Fowler, @martinfowler; David Heinemeier Hansson, @DHH)
[TDD] Do TDD well
When I read the Cucumber Book couple of years ago (the 2nd edition has just been released!), one of the eye opener for me was how Aslak and Matt described the relation of TDD and BDD. At that time, I thought that TDD is a set of very strict rules, including perfect unit isolation and a rigid following of the TDD steps. There were problems where I could use this kind of TDD and there were cases where I could not. It’s all my fault, I thought. Somehow I felt that there must be a higher level, test-first thinking principle that can be more generally applicable, but I did not think it was what we do with BDD. Matt’s post from 2012 is still valid, and it covers this perspective very well.
TDD vs BDD (Matt Wynne, @mattwynne)
[Test Automation] We miss the undersea tests!
I was working on a bugfix for SpecFlow. A great feature, covered with Gherkin scenarios, but still buggy. How is it possible? Actually, I realized when I started fixing that for this particular feature we only have SpecFlow tests and no unit tests. So while fixing, I was trying to analyse what caused the buggy code and how we could have avoided this. To my surprise, I found that the answer was related to the balance of automated specification (scenarios) and implementation verification (unit tests).
Balancing Scenarios and Unit tests (case study with SpecFlow) (Gaspar Nagy, @gasparnagy)
[Process] Collaboration on code with mobbing
I had a chance to join a couple of remote development sessions of the Cucumber team last year. They were working on Cucumber Pro and used a technique called mob programming. Mob programming that surely blows up your mind when you first hear about it: the entire team is working on the same piece of code together! What a waste! Or not? Steve Tooke from the Cucumber team has summarized their conclusions about mobbing and shared it with us.
The mob rules, ok? (Steve Tooke, @tooky)
Image source: https://medium.freecodecamp.com/nobody-wants-to-use-software-a75643bee654#.jcynm1qol
[Behind] Focusing on results
As a developer (but probably as a tester, or product owner too) it is so easy to get lost in the solution you have imagined for a problem. Maybe “lost” is not even the right word. Because you enjoy it. You feel the freedom of making something new. There is no problem with this, except that your freedom will produce a piece of software. A masterpiece of software, which will necessarily do what your users need. You should rethink software development. Bertil Muth’s post.
Nobody wants to use software (Bertil Muth, @BertilMuth)
