There you go, those are my 10 rules of (unit) testing. It’s nothing exciting, really. Everyone is so agile these days. Are you agile? I bet you’d say: I was born agile.
Here I come with my own 10 commandments. I came up with those while doing research on mock frameworks (haven’t you heard about Mockito, yet? it’s the ultimate tdd climax with java mocks). I browsed so much of our project’s test code that I feel violated now (codebase is nice, though).
- If a class is difficult to test, refactor the class. Precisely, split the class if it’s too big or if has too many dependencies.
- It’s not only about test code but I need to say that anyway: Best improvements are those that remove code. Be budget-driven. Improve by removing. The only thing better than simple code is no code.
- Having 100% line/branch/statement/whatever coverage is not an excuse to write dodgy, duplicated application code.
- Again, not only about test code: Enjoy, praise and present decent test code to others. Discuss, refactor and show dodgy test code to others.
- Never forget that test code is production code. Test code also loves refactoring.
- Hierarchies are difficult to test. Avoid hierarchies to keep things simple and testable. Reuse-by-composition over reuse-by-inheritance.
- One assert per test method is a bit fanatical. However, be reasonable and keep test methods small and focused around behavior.
- Regardless of what mock framework you use, don’t be afraid of creating hand crafted stubs/mocks. Sometimes it’s just simpler and the output test code is clearer.
- If you have to test private method – you’ve just promoted her to be public method, potentially on different object.
- Budget your tests not only in terms of lines of code but also in terms of execution time. Know how long your test run. Keep it fast.
Number #1 is my personal pet. Everybody is so test-driven but so little really care about #1 in practice. Best classes, frameworks or systems offer painless testing because they’re designed & refactored to be testable. Let the code serve the test and you will produce delightful system.
Number #7 is a funny one (‘Cos we need a little controversy). The whole world rolls in the opposite direction. Maybe I just don’t get it… yet. Or maybe it’s because I paired with young one-assert-per-test guy once. He cunningly kept writing test methods to check if constructor returns not-null value. If I had to play this game and chose my one-something-per-test philosophy I’d steal MarkB’s idea: one-behaviour-per-test. After all, It’s all about behavior…
February 13, 2008 at 10:39 pm |
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.
February 18, 2008 at 5:55 pm |
>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”…
February 18, 2008 at 10:18 pm |
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
February 25, 2008 at 8:44 pm |
[...] 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 [...]
April 11, 2008 at 7:14 am |
[...] 10 rules of (unit) testing de Szczepan Faber, auteur du nouveau framework de Mocks qui monte, Mockito [...]
May 8, 2008 at 9:35 pm |
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.
May 9, 2008 at 7:49 am |
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).
December 3, 2008 at 2:36 pm |
[...] 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 [...]