Comments on: 10 rules of (unit) testing

By: #Fellows | Rules of Unit Testing

#Fellows | Rules of Unit Testing — Wed, 23 Jun 2010 22:26:51 +0000

[...] any form of TDD it’s worthwhile to consider some basic rules. With notable exceptions of posts by Szczepan Faber and Michael Feathers, Google renders rather poor results on the subject so I decided to give it [...]

By: What make a good unit test? at Mark Needham

What make a good unit test? at Mark Needham — Wed, 03 Dec 2008 14:36:59 +0000

[...] used to try and follow the idea of having only one assertion per test but Sczcepan’s idea of testing one behaviour per class is much [...]

By: szczepiq

szczepiq — Fri, 09 May 2008 07:49:10 +0000

What I observed is that in language like java usually the easiest way to reuse code is inheritance. That leads to ugly software that is difficult to test and read. Composition over inheritance is simple and useful rule. It’s way easier to explain and adopt than elaborating on OOD&A (which as you say just few programmers actually know).

By: Sam

Sam — Thu, 08 May 2008 21:35:48 +0000

Rule #6 is retarded. It basically says, “Don’t worry about OO…it’s not that important”. Learn about “is a” and “has a” relationships. Composition over hierarchy is old Microsoft bullshit that they promoted because VB wasn’t OO.

It’s amazing how few programmers actually know anything about OOA&D.

By: Les 10 commandements des tests unitaires par J2EE, Agilité et SOA : Le blog de Xebia France

Fri, 11 Apr 2008 07:14:22 +0000

[...] 10 rules of (unit) testing de Szczepan Faber, auteur du nouveau framework de Mocks qui monte, Mockito [...]

By: Less is Better « Dynamic and Concise

Less is Better « Dynamic and Concise — Mon, 25 Feb 2008 20:44:01 +0000

[...] is Better A great blog post by Szczepan Faber talked about 10 rules of unit testing. In this post, I want to discuss on the [...]

By: Patric Fornasier

Patric Fornasier — Mon, 18 Feb 2008 22:18:18 +0000

Hey Szczepan!

#7 is a funny one, indeed. Remember when we laughed about it a few months ago? Yet I actually have sort of been convinced to write my tests in this way. Ok, ok, you might end up having a little bit more LOCs but I found that it does communicate the intent of the test better (and you can even name each intent in the form of a method name). Also, it seems to force me to slow down even more and take really small baby steps, which gives me more time to think about what I really want to code and which – in turn – hopefully leads to better code.

But as with all good things: don’t be dogmatic about it ;)

By: szczepiq

szczepiq — Mon, 18 Feb 2008 17:55:58 +0000

>Test code is executable narrative. It’s ok to have a bit of duplication if it makes it an easier read. I couldn't agree more! However, I prefer saying: "test code is production code" over: "test code is almost production code". The latter is too easily translated into: "test code is not production code"...

By: Dan North

Dan North — Wed, 13 Feb 2008 22:39:45 +0000

I agree with your #1. And even more so with your #7.

For me it’s about expressing one intent per example (or test, or whatever you call those little methods that ensure stuff works). If it takes a couple of expectations and an assert to express the intent, then that’s probably ok.

If it takes a whole bunch of expectations, several asserts and a couple of paragraphs of setup, then we’re probably in #1 territory.

I disagree with #5 a bit though. Production code is your application. Test code is executable narrative. It’s ok to have a bit of duplication if it makes it an easier read.