Jens Schauder is software developer since 1997. He loves software development for the constant challenges and constantly changing environment. A great chance to learn and teach. He is also blogger, author of various articles and speaker at conferences. Jens is a DZone MVB and is not an employee of DZone and has posted 89 posts at DZone. You can read more from them at their website. View Full User Profile

Getting Started with Testing

  • submit to reddit

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


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.


Published at DZone with permission of Jens Schauder, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Mladen Girazovski replied on Thu, 2011/08/04 - 5:14am

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.

Ok, i'll bite :)

When would the use of a mocking framework indicate bad design?

I think that you cannot apply TDD efficiently without a mocking framework.

Jens Schauder replied on Thu, 2011/08/04 - 3:15pm in response to: Mladen Girazovski

Thanks for biting :-)

One of the benefits of a mocking framework is that you can test stuff otherwise almost impossible to test.

One of the benefits of TDD is that you get strong and fast feedback what parts of your design are easy to test and which aren't. A Mocking Framework can interupt that feedback loop thereby damaging your design, which in turn forces you to use even more mocking.

More specific example.

If you have a method like this

public void doSomething(SomeType aParameter){



If SomeType and the objects returned by the methods called are non trivial, a method this is extremely hard to test. And considering it contains only one line of code it is pretty ugly from a design / clean code point of view. Yet with a mocking framework you can create a mock which returns  a mock, which returns a mock. This allows you to test this method. But it is still an ugly test and ugly code.

On the other hand with really nice clean code, it should be almost trivial to create an actual mock implementation of any class or interface without using a mocking framework.



Mladen Girazovski replied on Fri, 2011/08/05 - 8:12am

One of the benefits of a mocking framework is that you can test stuff otherwise almost impossible to test.

This might be true for mockito, but JMock2 for example (my favourite) doesn't allow for tricks like replacing static dependencies with mocks. The GoF Singleton for instance with the static getInstance method or the static INSTANCE attribute is still not replaceable with JMock2, and i think that this is a good thing.

I see your point however, if i can't write an isolated test easily and fast, something is wrong with the design of the class under test. Your example makes this clear, if the test is hard to write (mocks nesting more mocks etc.), then there is something wrong (law of demeter was broken in this case).

The only point where is disagree with you is that mocking frameworks could generally cover up such problems, Mockito is special in this aspect, what they sell as a feature i think of as a problematic backdoor that would allow to test even "not-so-good-designed-code", cause even if i managed to write a tests for bad code, it still remains bad code (refactoring would be the way to fix it).

I think that these issues will surface even without a mocking framework that supports "dirty tricks" pretty fast in a TDD project.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.