testing

We need to talk about 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?

Scratching a JUnit Itch

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.

Let your examples flow

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?

Monkey business value

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).

Article: Introducing Behaviour-Driven Development

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.