Getting Started with Testing
Getting Started with Testing
Join the DZone community and get the full member experience.Join For Free
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.
Opinions expressed by DZone contributors are their own.