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.
Friday, June 27, 2014
Wednesday, June 25, 2014
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.
Subscribe to:
Posts (Atom)