Integration Testing more important than Unit Testing

When I'm learning a new framework, strict unit testing isn't very helpful. To illustrate, here's an example:

I want to write a command object of some sort that interacts with jbpm. Jbpm is a workflow engine, with nodes and transitions. I need to look up a process (a collection of nodes and transitions), select a node and tell it to take a particular transition.

If I use EasyMock to ensure that I'm testing only my code, I can test whether the code is doing what I expect. However, that doesn't answer the most important question: Am I doing this the right way?

In my example, there are a couple of ways to look up nodes, and a couple of situations where the framework behaves differently than I expect. I can't find any of that until I do integration testing.

The paradox is that the authors of the framework don't have questions about which approach in their own framework is the correct one. Hence, testing integrations with the framework isn't attempted, and anything not attempted isn't factored into the design.

Bottom Line: Easy integration testing is key for rapid framework adoption.

Eclipse instant code coverage?

In general, I've drunk all the test-first kool-aid there is. My development is a constant cycle of write test, run test, write code, run test. Repeat until I think I'm done.

I really like code coverage tools, as they let you know if you're as done as you think you are. Are you testing that else clause or that exception case? Good stuff.

So why can't Eclipse show me which lines were covered by my *last* test run? I think that would be pretty useful, and it seems like the pieces are there to make it happen.

The Deal with Documents

When working up some process documentation, our group had a little bit of a revelation:

Documents exist to make a decision.

This single statement really helped us streamline what we were doing with our documentation, and our process itself. At each stage, we asked "What decision is trying to be made? What information is needed for that decision?" Everything else was junk, and we cut it out of the document.

Every time I write a document now, I ask myself that question.

LinkedIn end-run.

I was contacted today, by phone, by Dan Payne from Opsware. He "found" my information via LinkedIn. This was surprising to me, since I don't know Dan and was under the impression that LinkedIn worked by restricting people 's access to you through their invitation approach. What I'm pretty sure happened here is that the combination of real name + company name + google was quite enough to dig up my email address and to call up my employer and get to my direct line.

I hate that. That's not the permission I gave him, and it irritates me that LinkedIn made it possible. So, I sent a note to LinkedIn customer support complaining about this inappropriate usage. I'll keep you posted with how that turns out, but it sure seems like it should be in their best interests to keep people from using them to mine other people's personal data. We'll see how that turns out.

When is a property not a property?

There's a lot of talk about property support in Java 7. Some of the proposals allow you (like C#) to access the get/set methods without using the method name:

foo.bar //actually calls Foo.getBar() or a reasonable facsimile

Except now you've made a distinction between accessing it as a 'property' and accessing it via a method. What's the difference? Richard Blair says "read the docs", but I think that's the wrong answer. The language has made a distinction by allowing two ways to access code that makes multiple modifications to an object's state. If the distinction is meaningless, then it adds clutter. Any access to a 'property' needs to appear to be a method call to client code, because that sets expectations accordingly.