[melbourne-pug] Unit Testing (Following up TDD presentation)

[Peter Galaxy]

Hi Maurice,

I've also been trying out unit tests since seeing Bruce's
presentation, and also been retro-fitting my old code.

I've been working on a binary editor (Qubero) for sometime. I last
worked on it six months ago and thought I'd have another play with it.
Last time I worked on it, I'd just done a heap of fundamental
modifications to make it work on a bit level, rather than a byte level
-- (imagine an editor where you could delete a single bit and have
everything after it shift up like deleting a character in a word
processor). Anyway I'd done all these changes, and once I finally got
the thing to actually compile (it's in Java), I left it like that:
full of bugs. For six months. I've started to work on it again this
week.

My usual style of debugging is to make a big mess of print statements
with debug info all over the code until i can narrow down the problem,
fix it, and then comment out or delete the print statements. Instead
I've been creating unit tests.

So now I have a small but growing collection of unit tests for my
project. They're not as thorough as if I'd started with TDD. I'm not
sure how different my coding style would be if I had: i tend to think
in terms of interfaces anyways. But at least I have some tests now,
and I'll still have them later for regression testing.

I've still resorted to the old fill-code-with-print-statements style a
few times, but doing that has also benefitted from unit tests, as they
make it easier to control what code is being executed for doing the
debugging with. And you're left with a new test case in the end. By
comparison, debugging by playing the program's GUI is pretty
inefficient and can generate huge amounts of debugging output.

I've been coping surprisingly well with my sparsely commented code,
and fixed a heap of problems in a short time. It's working well for
me. And the test cases also act as a form of documentation.

Peter.