Testing

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.

Josiah Renaudin interviewed me in May 2015 ahead of the STAREAST conference in Orlando. The original interview is online at AgileConnection.

…or why Mockito is my new friend.

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 prioritising very well. I should fix that.

So I was hanging out with a bunch of geeks in Switzerland, having one of those late night conversations, and an idea sort of emerged, and the more I thought about it, the more I liked the idea. And then I was thinking that a) I’m useless at following through on ideas and b) I would love someone to take this forwards. So here it is. Our premise was that the value of automated testing is in its repeatability and low investment (in terms of human effort).

At the beginning of this year I wrote a feature article for Better Software magazine, which was published as “Behavior Modification” back in March. The article is now available on my site. It gives an overview of behaviour-driven development, from its origins as a coaching aid for TDD through to its current form as a proven, comprehensive development approach.