[LRUG] LRUG 8th May 2006

[benjohn at fysh.org]

> Hi Guys,
>
> I would be more than happy to give a talk on TDD on Monday the 12th of
> June - if we're having an lrug on that evening. I would have liked to
> have it ready for the next meeting but I'm just really busy.
>
> If there is anything specific anyone would want me to go through
> during the presentation, please feel to drop me an email. It would be
> great to get a feel of how much people already know about TDD.

I've been using TDD on my current project, and it's splendid. I think
one of the most important things about it is that it forces you to
design the interface before you implement it. (Which is intriguingly
mirrored by a best practices in application design: design the interface
and then code for it; rather than write the application and fit on an
interface).

Ruby specifically, something that's been giving me some trouble though...

I'm making use of Ruby's open classes. Several of my classes have their
basic behaviour in one file. In other files, specific aspects of their
behaviour are filled out.

In fact - I also use this for configuration. I patch a class (by
requiring a file) that alters its behaviour to fit a particular task.

I have tests for aspects of the classes' behaviours. When building these
tests, it's convenient to leave out chunks of behaviour, and test the
other aspects in isolation.

The problem I've encountered is that when I use testrb to execute my
tests, is gathers all of my tests in to the same global namespace. This
stops them being "hygienic"; they interfere with each other, and all of
the tests are exposed to the full implementations.

I can think of several work arounds to this. I could:

  stop using Ruby's open classes like this, and use some other mechanism
to tie together behaviour at run time (all sorts of dependency
injection mechanisms are out there, and there's aspects too).

  write a new test executer to run the individual tests in their own
processes (probably easy).

  "fix" the test executor (had a brief look, and it looks a tad hairy).

  place my unit tests, and the components tested by them, in to their
own modules (require defaults to the global scope - there are
work-arounds certainly, but they don't seem nice - particular problems
come from the recursive requires in the files being tested).

... :) So if you had an answer to that, I'd love to hear it :) But I'd
love to hear it before the talk, as cleaning up our unit test hygiene is
part of the next iteration.

Cheers,
  Benjohn