Unit Testing With Threads

I saw this and started thinking back on a calculus course at university.

Wouldn't we expect a theorem like this to be true:

"for all codebases C and features F, there exists a set of refactorings R and unit test U, such that U(F) is safe under R(C)"

In other words, can we not manipulate any piece of untestable thread code into a testable one, given enough refactorings and inversion of control levers (and effort!)? Seems reasonable to me.

In a situation with 2 threads and one interaction, it is easy to imagine the combinatorial complexity of test cases. It of course explodes when the numbers go up - but perhaps we could argue that for any number of threads and interactions, we can reduce the complexity of our tests by looking at each in isolation...

If my theorem holds, you can of course turn it around and use it to knock people over their heads when they screw up thread testing - hmm, how productive that would be :-)

Interesting thought, anyway.

Surprisingly Good Error Messages!

I was stunned recently by finding a piece of software that does something reasonably complicated, but still manages to give good error messages.

Just look at this beauty from Spring IOC:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'magiceightball' defined in file [C:\...\random\magiceightball.test.xml]: Cannot resolve reference to bean 'randomsource' while setting constructor argument; nested exception is org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find class [foo.Foo] for bean with name 'randomsource' defined in file [C:\...\random\magiceightball.test.xml]; nested exception is java.lang.ClassNotFoundException: foo.Foo at [...]

That is actually perfectly readable! Alright, I am a nerd, and I have some experience with debugging Java code, but I bet a 9-year-old child could deduce that they forgot to implement a RandomSource called Foo.

I was stunned when I saw it, perhaps because it is so rare to get useful error messages from clever frameworks. As soon as reflection enters the picture, people just give up it seems. Look at this example as a contrast:

com.google.inject.CreationException: Guice configuration errors: 1) Error at foo.BarTestModule$TestBar.(BarTest.java:18): Could not find a suitable constructor in foo.BarTestModule$TestBar. Classes must have either one (and only one) constructor annotated with @Inject or a zero-argument constructor. 1 error[s] at com.google.inject.BinderImpl.createInjector(BinderImpl.java:277)
[blah blah]

Hmm, that's funny, I distinctly remember creating a zero-argument constructor in TestBar??? It turns out, Guice does not support injection of inner classes. And it only took me an hour to figure that out... So is this error message helpful, or rather harmful?

Hibernate is equally bad and will give you a lot of grief if you do not tread carefully. And these are popular, high-profile pieces of software, not random open-source amateur junk off of SourceForge. So how come Spring IOC got it right and these guys got it so wrong?

T-shirt Size Estimation

We have all been through painfil estimation sessions. What makes them painful is formality.

The Living Room Architect talks about a Story Matrix, as a way of facilitating a smoother flow for estimating a bunch of stories. Good idea.

One problem still persists though, is the formality of it, with the whole points debate: do we use Fibonacci, linear, exponential, what? What do the numbers mean? And the apprehention on the part of us developers to be specific with stories they have only just begun to think about.

Someone today introduced me to T-shirt Sized Estimation - you basically cluster your stories into S, M and L. Sizes cover plain "lines of code", complexity and risk. But it has an implied light touch which seems to solve some problems I think, it seemed to go quickly and easily, and we did get a result out of it.

• No numbers, so nothing to get too hung up about
• Only 3 categories, so we don't have to discuss things for very long - it is implied that this isn't the final clustering
• We still got to communicate about the stories, so Agile Tick Mark™ right there
• And we got a rough set of estimates

Now, that isn't of course the final word in the estimation process, and we all know that, so no point in getting defensive. We will need numbers at some point. But it got us perhaps half way. We did talk about our understanding of the stories, and we did get a picture of how hard the project might be.

But most importantly, we didn't get hung up on details - instead we split the process into 2 (or more) phases. A bit like when you look at algorithms, you know that when you need to traverse a graph and do something complicated, you can either write the mother of all recursive functions, or you can split up into separate stages (search and modify stages for example). In the end, we all know that O(n) + O(n) = O(n) - i.e. the amount of effort will be the same, but it will be easier to manage the two things separately.

We will certainly need another card session, and we will need some numbers at some point, but for now we have fleshed out some things, in a very short time and noone has run off crying. And that has to be considered progress.

Schema Spy

While reverse-engineering a customer's database, my pair-mate introduced me to Schema Spy. It looks quite good: lightweight cross-db reporting and visualization, runs from the command line and gives you an HTML folder structure.

http://schemaspy.sourceforge.net/

Top 10 Books On Software

A friend of mine blogged about books. His question was: "What are, in your opinion, the top 10 books that every software engineer/developer should read?". Well, here are a few to get you started:

• Gamma et al.: "Design Patterns". An absolute classic. After reading it I immediately went into pattern fever (as everyone does?). Interestingly, the patterns themselves aren't that useful for the stuff I do day to day, but the idea is powerful. And of course, this book started the whole Patterns Movement...

• Møller & Schwartzbach: "An Introduction to XML and Web Technologies". I am slightly biased, having taken an XML course from the authors. But, this book really puts things in perspective, it is thorough and clear, and offers opinion. The web is full of simple examples, re-hashes, cheaply written stuff without depth. So this was a great and welcome read.

• Larman: "Applying UML and Patterns". This one really hit the spot. I was idling somewhat, lacking direction, and this one gave me a spark of inspiration. The way it formulates those simple, old-fashioned OO values, it takes you back to first principles and reminds you why it is we do what we do. It is easy to get lost in new technology, tools, methodology and process - but what we really need is to remember those few, simple things: model your domain, separate concerns, an Bob is your uncle!

All The Cool Kids Have A Blog

All the cool kids have a blog, so I think I should have one too. That is about as much reasoning as I can muster right now.

I am always impressed with blogger's boldness, the way they reveal their hand to the world and take sides. I wonder if I will be as brave? I like to ask questions. Do questions belong in a blog? Or does it only work if you have that blogger-swagger?

Anyway, we shall see what comes of it!