Getting Started with Testing
In a recent article I described how important I consider the practice of Testing, especially in the form of TDD.
Erik made a real good comment on that article:
“Start learning how to test today”
Do you have any good resources?
“Most of the code we produce isn’t fizz buzz, but is concerned with GUIs and databases, both make testing hard and expensive. But these problems can be solved, so you can gain the benefit of TDD even for these cases.”
How?
I’ll try to answer the first question today, the other one will have to wait.
TDD encourages good design (at least on the class level), because code that isn’t nice and modular is hard to test. Therefore I recommend as a first resource the best book I have read on that topic: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin also known as Uncle Bob. Actually you should as much stuff written by him as possible, e.g. his principles of OOD. If you are into twitter you might follow him there
There are plenty of books about testing, but I have to admit I wasn’t tremendously impressed by any of them. But they are still usefull.
A good introduction into TDD is Test Driven Development. By Example (Addison-Wesley Signature) by Kent Beck. This book is for TDD beginners. Although the two examples he is working on through the book aren’t trivial they do have the appearance of examples and probably differ a lot from what you’ll find in real life. But in every topic you start with simplified tasks in order to get started. For this purpose I can recommend this book.
The first book I read on this topic is Test Driven: Practical TDD and Acceptance TDD for Java Developers by Lasse Koskella. It starts with very simple stuff, but also covers things like acceptance tests and mocking frameworks. There is one tip from the book that I remember especially well: Don’t access thing like the system time directly, but use a simple service which implements a simple interface. If you do so you can stub/mock that service which helps tremendously when testing time dependent code. Without this, how are you planning to test that your code works correctly across the change from daylight savings time and back?
Possibly the best book about testing I read so far is Working Effectively with Legacy Code by Michael C. Feathers although it actually isn’t focused on testing in itself. He writes about legacy code which he defines as code without test. So I guess for many of us this is most of the code we are dealing with on a day to day basis. Most strategies he describes are about bringing convoluted code bases under tests. Very helpful, although I’d wish I’d never need these strategies. Although the code examples in the book are shortened to fit into a book you can ‘smell’ the bad code found in real world projects.
Of course I haven’t read everything available about testing. So there is still stuff on my whish list, like for example Growing Object-Oriented Software, Guided by Tests.
All the reading doesn’t help as long as you don’t put the stuff you read about into action. So start writing test. For the start stay with simple stuff. Where you can immediately write down the test. You might wonder if the test is worth the effort for such trivial code. But remember you are trying to learn. And learning is done by practicing over and over again. You will find situations where you realize writing the test isn’t as easy as you thought. Try to write the test anyway. Try to find a solution for the testing problem. Ask at stackoverflow how to solve the issue.
Learn a testing framework. Learn a second one. Learn one in a different programming language. A long the way you will learn a lot about different styles of testing and different solutions to problems.
Learn a mocking framework. I’d recommend Mockito. Try not to use it. Find out why using a mocking framework might be a sign of bad design.
Enjoy the ride. And add recommendation as a comment.






Don’t agree with your second last paragraph. You miss a not in “Find out why using a mocking framework might be a sign of bad design.”, don’t you?
If not, I am interested in knowing why using a mocking framework is a bad idea.
@Schakko
no, there is no ‘not’ missing, although the statement is intentionally provocative.
With most designs that I’d consider beautiful, there isn’t much need for mocking frameworks, since the classes are so simple, it is easy to implement a quick mock.
The more your design rots the more complicated gets the usage of mocking frameworks. If you find using spies for example (http://mockito.googlecode.com/svn/tags/1.7/javadoc/org/mockito/Mockito.html#spy%28T%29) your class might violate the single responsibility rule.
Problem is that mostly it’s not your bad design, that raises the idea of using a mocking framework.. but I encourage your provocation
… and moreover spies are in most cases a bad idea.
The ability to do “dirty” things is very useful with classes you don’t control. That’s why I like Mockito. Thankyou for pointing out that this capability is over-accommodating of bad practice in one’s own classes. I hadn’t noticed the reverse side of that particular coin.
For those who do want to do dirty things in their tests, there’s another tool called JMockit which apparently has even more capability than Mockito, able to mock static methods. I know this because I wrote a blog+Dzone post a while back about unit testing, in which I stated that such dependencies were impossible to substitute. I got a rather sharp reply from JMockit’s creator to tell me that I was wrong.
@Spencer (and everybody else interested) there is also PowerMock which allows to mock static stuff and constructors. It works together with Mockito and (I think) various other mocking frameworks.
[...] might be a sign of bad design. Enjoy the ride. And add recommendation as a comment. Reference: Getting Started with Testing from our NGC partner Jens Schauder at the Schauderhaft blog. Posted by Nikos Maravitsas [...]