Tdd

Or how programmers and testers can work together for a happy and fulfilling life.

Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?

tl;dr #

• I like JUnit. It is simple and clean, and it is ubiquitous in the Java world.
• I like Go’s testing package. It is even simpler and cleaner, and distinguishes between failed checks and fatal test failures. It doesn’t use exceptions to do this.
• I wanted to see what Go’s testing semantics would look like in JUnit, so I wrote JGoTesting. Some people helped me.
• I’m quite pleased with how it is turning out so I want to share it with you.

I’ve just come back from the excellent NDC 2012 event in Oslo, where they published my article about opportunity cost in The Developer magazine ahead of the conference.

I’ve noticed a number of people recently declaring that BDD really is just TDD, such as Robert Martin on Twitter and Ron Jeffries on the XP list. I can understand where this mindset comes from and I’d like to offer my perspective.

A friend of mine has a Far Side desk calendar that he describes as a barometer for how busy he is. Some days he finds himself tearing off a whole bunch of pages because he’s been too busy or distracted to tear one off each day.

It’s finally happening - I’m writing a book! Well ok, the remarkable David Chelimsky is writing a book. It’s called Behaviour Driven Development with RSpec, Cucumber and Friends and myself and a few other folks are contributing in varying degrees.

…or why Mockito is my new friend.

Some ancient history #

Back in 2003 I started work on a framework called JBehave. It was an experiment to see what JUnit might have looked like if it had been designed from the ground up for TDD rather than as a unit testing framework. I was also starting to use the phrase “behaviour-driven development” to describe what I meant. The jbehave.org domain was registered and the first lines of code written on Christmas Eve 2003, much to my wife’s bemusement. Over time JBehave grew a much more interesting aspect in the form of a framework for defining and running scenarios, or automated acceptance tests.

Should examples/tests/specs/whatever be DRY (Don’t Repeat Yourself)? I’ve been thinking (and talking and arguing) about the value of test names recently and whether they are just unnecessary duplication, but that’s the subject of a future discussion. This is about the actual content of your examples. So, should your examples be DRY?

I’ve been pretty slack at letting people know about upcoming talks. I could blame workload or burnout or any number of other plausible-sounding reasons, but a lot of it is just down to not prioritizing very well. I should fix that.