Chatty unit tests

Did I mention this blog is going to be a bit stream-of-consciousness, hopping around from topic to topic? Anyway, wanted to talk today about “chatty” unit tests–unit tests which produce logging output when they run. Most of the time this is due to logging statements from the class under test. Now, most of our Java classes use commons-logging in the following fashion: public class Thing { private static final Log logger = LogFactory.

Calling super() considered harmful?

Had an interesting discussion yesterday about how to solve the following problem: * You have a class (in our case, it was a Spring MVC controller) which has some dependencies injected, and which you, being a good defensive programmer, want to check that all the needed dependencies are present. * Since this is a Spring app, it’s ok to use the InitializingBean’s afterPropertiesSet method somewhere in here. * We want to derive some subclasses from the base class that introduce additional dependencies that we want checked, but we want to continue checking the superclass’s dependencies.

Programmable IDEs

Ok, I’ll admit it. I still use Emacs as my “IDE”. It’s what I started programming with when I was learning Unix/C in college, and it’s always served my needs well. Nowadays, I pretend to be a Java developer, and Emacs still works fine for me. I’ve been meaning to try Eclipse for some time now, but have ended up having issues getting it to work on my 64-bit RHEL workstation, and I just haven’t had time to make it work yet.

Code Craftsmanship

Writing software is as much a craft as furniture making. Someone can ask for a chair, and different furniture makers will produce different chairs. Hopefully most of them will support your weight when you sit in them, but the sturdiness and aesthetics will vary, as will, most likely, the particular joints, types of wood, etc. Obviously, writing code is quite similar; there’s getting the job done, and then there’s getting it done well.