The Problem
While reading code in real life situations, whether it is an open source project, your own code written long long time ago, your collegue's or team's code or something that just popped out several seconds ago, you may find yourself in situations, which will make you scretch your head for minutes or even hours.
If it happens, you are probably just looking at one of these:
It may even be a combination of the above. If your project is more than a small one, and you will have to work with it for the next couple of weeks, months or even years, the damage has already been done.
And now what? Will you spend extensive amount of time trying to fix everything? Are you or your manager willing to allocate enough time to rewrite everything? Will you invest your free time? Does it have any value or is it even feasible? The answer will probably be: "No".
Situations like this have to be avoided, and every developer should know how to identify and prevent bad code.
The Solution
If you were hoping, that I will reveal a magic formula for fixing bad code or write over the top quality UT, I have to dissapoint you. There is no single uniform recipe to write great UT. Fortunately, over time we have learned what are well known bad ways to do so.
By studying these ways and learning how to avoid them, you will make yourself and everyone who has to work with your code much happier.
Articles, Blogs, Books and Materials every Programmer Should read before writing any Production Code
- Clean Code: A Handbook of Agile Software Craftsmanship from Robert Cecil Martin (Uncle Bob), must read for every programmer without discussion
- Guide-Writing Testable Code, a very complete Guide with actual code samples. Many of these guides can be found on Miško Hevery's blog:
- Petri Kainulainen's Blog, namely Writing Clean Tests Tutorial
If you are not convinced or do not think, that having a clean test suite or even code base is necessary, try to read Benefits of Testable Code interview at DZone.
Need more reading?
