Before I wrote a line of code for cmeScribble I decided that I'd code
it the right way. Retrofitting "right-way-ness" onto an existing
project is almost impossible, so I was determined not to miss the
chance to build it in from day one.
The particular "right way" I had in mind was using Test-Driven
Development, or TDD. For anyone unfamiliar with the TDD methodology,
the idea is that before you write any code or fix any bug you first
write a test or two to make sure the code works or the bug is fixed.
The test should fail when you first run it, because the code doesn't
work and the bug hasn't been fixed. Once you've written the test and
verified that it fails, then you write the code to make it pass.
The advantages of TDD are well-documented elsewhere, but in a nutshell:
writing the test forces you to know in advance exactly what you want
the code to do, and also as you develop more and more code you have a
library of tests to make sure you don't break anything.
I could easily see how to write tests for self-contained functions, but
I couldn't figure out how to write tests for user interfaces or
database-backed logic. Since cmeScribble is all about building user
interfaces from database data, this posed something of a challenge.
Maybe I can get away without testing the UI layer, but I can count
features that won't need database data in some way on the fingers of
Captain Hook's right hand. Okay, I thought, Google to the rescue... but
searching for databases and TDD provided lots of people with similar
issues and no straightforward answers.
A common suggestion was to use "mock objects". The idea is that you
create a "fake" version of your database layer which returns plausible
values without actually needing a database. This solves the problem but
the downside is that you have to actually write the mock version of
each database table, and since cmScribe has over a hundred tables at
last count I didn't relish that thought much either.
Facing a potential deal-breaker for something you don't want to
compromise on tends to focus the mind, and eventually I hit on a
solution. A full SQL database is hideously complex, but cmeScribble
will be doing it's database access through nrdo (I'm biased, but I
honestly don't see how people can work any other way...) and for 99% of
uses, nrdo provides a fairly simple object model over the top of the
database. Simple enough that if you don't care about persistence (which
in a test situation is actually a bad thing) or performance, it's
possible to implement the vast majority of it very simply in memory, as
part of the nrdo runtime library and generated code, backed by simple
List<T>s. A couple of days of hacking later and that's exactly
what I've now checked into nrdo's CVS: If you use the C# 2.0 template
and set the configuration setting "NrdoMock" to "True", all your code
will run purely in memory, with a clean "database" for each run.
There are a few things missing - at a wild guess I'd say it covers 60% of
what you'd want to do right now, and I should be able to get that up
to about 90% without too much trouble by filling in things as I need
them (after writing tests!). Most of the rest can't be handled
automatically (because they'd require a full SQL engine in the mocking
layer) but can be done with a little manual intervention (by the
programmer providing a C# equivalent of the SQL clause in question; the
SQL clause itself doesn't get tested but all the logic around it does).
The most satisfying part of the whole thing was watching it pass the tests I'd prepared in advance :)
 cmeScribble will have a lot less because of the "enterprise"
features that aren't being included and also hopefully by unifying lots
of things that were separate tables in cmScribe, but still.