Unit Testing Private Methods

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

A Bug, a Trace, a Test, a Twist

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

Session-based Logging

To trouble-shoot software, logging of some kind is essential. But for most systems, it is simply not possible to log everything that happens. Many systems and logging frameworks let you limit the amount of data by giving a logging level (e.g. error, warning, info, debug) and by specifying where in the code logging should be done. An alternative way of limiting the data is to use session-based logging. You then get all data pertaining to a specific session, but nothing for any of the other sessions. Continue reading

Finding Bugs: Debugger versus Logging

One common reaction to my post on writing debuggable code was: you don’t need logging, just use a debugger. While there are cases where a debugger is the best option, there are many reasons why having proper logging in place is superior to using a debugger for trouble shooting. Continue reading

TDD, Unit Tests and the Passage of Time

Many programmers have a hard time writing good unit-tests for code that involves time. For example, how do you test time-outs, or periodic clean-up jobs? I have seen many tests that create elaborate set-ups with lots of dependencies, or introduce real time gaps, just to be able to test those parts. However, if you structure the code the right way, much of the complexity disappears. Here is an example of a technique that lets you test time-related code with ease. Continue reading

Automatically Include Revision in Log Statement

When there is a problem with your software, the first thing you usually ask for is a log showing what happened (provided you write debuggable code), and the version of the software that was running. But it is easy to have the revision of the software automatically added to the log. Continue reading

7 Ways More Methods Can Improve Your Program

A lot of code I come across consists of relatively few, but long, methods. The code does what it is supposed to do. However, it could be improved a lot. Refactoring to use more methods can produce better structured programs that are easier to understand, easier to modify, easier to test and easier to debug. Below are 7 reasons why using more methods can be a good idea.

Continue reading