Good Test, Bad Test…

Developers shouldn’t think of writing tests as like writing code – they should think of it as *exactly* the same as writing code. IMHO, the “code” is has 2 parts, the implementation and the tests, and each needs as much care and attention as the other… Anyhoo…

A test remarkably similar to the following cropped up recently:-

def a_test(self):
   ...
   self.assertRaise(SomeError, self.foo(x, y, z).blargle)
   ...

Now, to paraphrase the legendary Mr Clough – “It’s not the worst test I’ve ever seen, but it’s in the top 1” ;^)

How can such a small test be so bad? Well, it manages to pack a couple of critical errors into a single line (and that’s some going I have to say ;^):-

1) It is not clear whether it is the method call or the attribute access (or both) that is expected to raise the exception.

2) The implied API is clunky at best. If the reason for calling the method is to get hold of the “blargle” then just return the “blargle”! The only thing that this test makes clear is that the API is not clear!

If I was a betting man, I would bet that this test was written after the implementation, which might excuse the API weirdness (it could be the start of refactoring a legacy API), but not the lack of clarity…

Blocks and Procs

If a function/method uses a block, why would I ever use the implicit ‘yield’ syntax instead of explicitly pass the block as the final ampersand argument?

e.g.

Why would I do:-

def foo(x)
  yield x
end

Instead of:-

def foo(x, &block)
  block.call x
end

Doesn’t the implicit syntax hide the fact that the function/method allows a block from the caller, meaning that the only way to discover it is to read the code?!? What am I missing?

Two types of information?

As I’ve mentioned previously, I like the idea of attaching metadata to my information so that I can view it in many weird and wonderful ways, and not just how a random developer decreed it should be viewed (especially scary, is the infamous “I’ve got a tree control and I’m gonna use it” kind of developer!).

Now, in Web 2.0-Ville that (for now) means tags, and so I did the dutiful thing and signed up to delicious and I was happier than a happy thing from Happy-on-Sea, going about adding all of my bookmarks to it, when I hit the ‘restricted bookmark’ issue whilst trying to delicious-ize (whats the right verb?) a link to a directory on a local disk. Now I understand that because delicious is at its heart a tool for sharing, I don’t want to expose private information, but it is still a little disappointing. It means I can’t access my information in a unified way simply because of where it is stored, even though in this case, all I wanted to bookmark was a read-only document containing train timetables and I wanted it tagged with the rest of my #admin stuff!

Maybe, in the war to organise my information, there really are only two types – private and shared (I won’t say “public” since shared implies a finer grain of control)…

We are still a ways off yet, of course, since I would really like to attach semantics to my tags and have those semantics shared with everybody else, but we’ll get there I’m sure…