Day 5: Write a Unit Test Before Coding
Hi, this is the fifth part of a series of posts on 30 tips to becoming a better developer. If you would like to keep up to date with the topics that I am covering, just check the main post.
From all trends of software development in the last years, few are so important and useful as test-driven programming. Testing in general and unit testing in particular are an essential part of any software system and cannot be left to the last moments.
In the past, testing was considered to be almost an afterthought. The idea was: to have a bug free system, build, then test. That was in the early days, when people believed in the waterfall model and in Santa Claus.
Thankfully, experience has shown that nothing could be further from the truth. If testing is not added to the day-to-day of building the system it is really hard to make sure that final testing will work at all. Another way of viewing this issue is to understand that testing isn’t important only at a single moment in time. Instead, it is necessary during the whole process of creating software, the same way compiling is necessary at each iteration.
Unit Testing as “Extra Compilation”
The workings of a compiler provide a good analogy for unit testing. Think of unit testing as an extension of compilation where you are testing for dynamic properties of your code, instead of static properties. For example, the compiler will easily check syntax errors and identify areas where you are using the wrong data types. Unit testing, on the other hand, will identify potential errors in the way you are implementing algorithms. The best thing of unit testing is that you are free to perform any test that can be possibly implemented in your programming language. Thus, you are not limited to checking for static properties, as your compiler is, but you can extend your checking to any dynamic property whatsoever.
What is the Catch?
Well, the catch, if you look at it in this way, is that you need to plan for testing. In reality, the main reason why it is difficult to test existing code is that it was not designed to be easy to test. Examples abound, like the common case where an object has concrete dependencies on many other objects, which creates a nightmare for someone who wants to test a class in isolation. There are several cases that can be considered when writing testable code, but the easiest way to solve these issues is to ask yourself before starting to code: how can I write a test for this functionality? Once you ask and answer this question, you will have everything you need to make unit tests that work and that are appropriate for the feature you want to implement.
Write a Test Before Coding
This can be summarized as saying that you should write a test for features you want to implement before writing the code. The reason is that if you are able to create a test for a feature, you will consequently implement it in a way that can be easily verified. And this happens just by the way you implemented the feature. Most people fail in this simple step and compromise all the time spent in coding. If you have to rework your code to test it, you might just as well be adding bugs that were not there before. So, adding unit tests after the case can, at least initially, damage something that was working fine.
Conclusion
Testing is good, and nowadays more and more people are aware of it. However, the catch is that you need to code with testing in mind, or you risk losing your time, instead of reaping more of the benefits. Writing tests before you code is a smart way of avoiding problems that might arise when creating unit tests.
Further Reading
- Pragmatic Unit Testing, along with its sibling for C#, cover practically everything you need to understand about testing, including coupling issues, mocking objects, and more.
- Test Driven Development teaches you how to develop based on tests. It is a great book with lots of examples for you to get used to this methodology.
Go to the next post of the series:
