I recently found out about the book Developer Testing – Building Quality Into Software by Alexander Tarlinder, and I immediately wanted to read it. Even though I am a developer at heart, I have always been interested in software testing (I even worked as a tester for two years).
I think the subject of the book, developer testing, is timely. There seems to be a broad trend where more and more responsibility for testing is given to developers. It follows from the move towards micro services, dev ops and the “you built it, you run it” principle. Another driving force is the prevalence of developer testing frameworks that started with JUnit and now includes many more. These frameworks encourage and help developers write automatic tests.
Despite this trend of increasing developer testing, my feeling is that many developers still don’t test their programs well enough. For example, they may test the “happy path”, but not the different error handling cases. That is why I was excited about this new book explicitly addressing developer testing. Continue reading
In Learning From Your Bugs, I wrote about how I have been keeping track of the most interesting bugs I have come across. I recently reviewed all 194 entries (going back 13 years), to see what lessons I have learned from them. Here are the most important lessons, split into the categories of coding, testing and debugging:
Bugs are great learning opportunities. So how do we make sure we learn as much as possible from the bugs we fix? A method I have used for more than 13 years now is to write down a short description of the bug, the fix, and the lessons I learned.
Way back in 2002, I came across a blog post (that I unfortunately can’t find again) that described this method. I have used it ever since, and I believe it has helped me become a better software developer.
Every time I fix a particularly tricky or interesting bug, I take a few minutes to write down some facts about it. Here is an example of a typical entry: Continue reading
A few months ago I came across the article Why Most Unit Testing is Waste by James O Coplien. The title is an accurate description of the contents – James considers most unit tests to be useless. He expands his arguments in the follow-up article. I was quite intrigued, since I get a lot of value from unit tests. How come we have such different views of them? Had I missed something? As it turns out, I was not persuaded by his arguments, and here is my response to the articles. Continue reading
When I first heard about unit testing using a framework like JUnit, I thought it was such a simple and powerful concept. Instead of ad hoc testing, you save your tests, and they can be run as often as you like. In my mind, the concept didn’t leave much room for misunderstanding. However, over the years I have seen several ways of using unit tests that I think are more or less wrong. Here are 5, in order of importance:
How can you unit test private methods? If you google this question, you find several different suggestions: test them indirectly, extract them into their own class and make them public there, or use reflection to test them. All these solutions have flaws. My preference is to simply remove the private modifier and make the method package private. Why is this a good idea? I will get to that after I discus the problems with the other methods. Continue reading
Here is the story of a bug that I caused, found, and fixed recently. It is not particularly hard or tricky, and it didn’t take long to find and fix. Nevertheless, it did teach me some good lessons. Continue reading