Boat table v2: In Progress

There are grand plans underway to completely rebuild the boat table.  Two days ago I got the basic frame cut, then last night I put in the dado for the glass insert.  Coming along!

Also, I learned that when a board hits you in the face, it hurts.

Spring autowired testing problems

Lately I’ve been working on putting tests around some of our legacy (ie, untested) code.  Much of the app uses Spring’s auto-wiring, so we have fields that look like:

private @Autowired FieldValidator fieldValidator;

Spring can wire this together reflectively so there is no need to write a constructor or setters.

Therein lies my problem.

Without a constructor or setter, how can I (easily) write tests that inject mocks?  As far as I can tell, the official solution is to use Spring’s ReflectionTestUtils class that has a method setField to set these private instance fields.  I have two issues with this though.

First, it is very reflection’y, which is to say, not a natural code style.  Instead of action.setFieldValidator(mockValidator) that looks and behaviors like traditional Java, we are stuck with ReflectionTestUtils.setField(action, “fieldValidator”, mockValidator).  Yes, I can read it and know that it’s doing the same thing, but it’s not nearly as intuitive.  Even statically importing ReflectionTestUtils still leaves me with a setField method that requires a target instance and method passed in instead of, you know, passing something directly to the instance.  There’s a bit of a feeling of IoC here, which makes sense coming from Spring; but for a unit test, I WANT the control.

Second, and more importantly, it isn’t safe.  We have powerful IDEs to do everything except make toast (although, I wouldn’t be surprised if there’s an emacs command for that too), yet formidable Spring’s best advice here doesn’t make a peep at compile-time when there’s a flagrant error?  Try to pass in a value that isn’t compatible with the field?  Find out at runtime.  Typo the field name?  Find out at runtime.  Change the target and thus break the rest of the setter?  Find out at runtime.

No IDE will update this line when you refactor your code.  You should be able to change a private field safely basically at no expense, but now you’ll break your test – and won’t know it until it runs.  I understand that a test can and should be tightly coupled the class under test, but if they’re going to be coupled, can’t we at least keep them automatically in sync?

So if you use Spring’s autoMagic Autowired without a constructor or setter, how do you mock your tests?   

I’d love to know.

New programming font

Earlier I was reading Dan Benjamin’s hivelogic.com post of the Top 10 Programming Fonts. I’m not exactly a fontiphile* so it doesn’t bother me the article is from 2009.

For most of my programming life, I’ve just used whatever my editor’s default font is.  Sometimes that’s Consolas, other times it’s Courier New or Lucida Console.  But for being what I spend the bulk of my day looking at, maybe it’s worth a little bit of thought.

I have to commend Dan’s selection and order.  Though I couldn’t exactly describe what was different about each font, I liked each one better than the previous.  Never did I say, “Eh, not feeling this one.”  I decided to start using his first choice: Inconsolata.  Actually, I’m using a modified version by David at nodnod.net called Inconsolata-dz that has straight single- and double-quotes instead of angled.

Download it: http://media.nodnod.net/Inconsolata-dz.otf.zip

So far, I’m enjoying it.  Easier to read at the same size and no complaints yet.

* Disclosure: I once was stuck in a car on a five hour trip with two journalism students that were copy-editors at the student paper.  They spent an hour discussing their favorite Serif fonts.  Then an hour discussing their favorite Sans Serif fonts.  Then discussing their preferred kerning styles.  I was weighing the pros and cons of killing them both – they just barely made it out alive.