My first unit test

As mentioned before I’m starting the (re)design for our upcoming major release. This is an exciting time because we will be using a couple of new techniques here. One of which is DevExpress’ XPO, eXpress Persistent Objects.

I had done some tests before, but now the real work starts I find that typing the object model rather than drawing is a big down side for XPO. I’m afraid that in this day and age you really need a visual modeller.

That said, I’ve bitten the bullet and started the design. I took that a bit light-hearted and thought I would have done that in a couple of hours. You know, thinking: “what do I need to do different compared to our current object model? It’s all been done and we know exactly what we want”.

Not, I can tell you. I find that rethinking over the object model brings up a couple of flaws that only become apparent if you don’t think of databases anymore. If you think in objects only, you experience another kind of designing entirely. I’ve been object modelling for quite some time, but doing it for real while reverse engineering a larger model is quite different to what I did before.

But, the reason I started this post is I wanted to share my first unit test with you. I was looking in the XPO software for a ‘model checker’. Since XPO is about storing data, and you need to specify the object relations using ‘code’, I suspected I might have mistyped something somewhere and wanted to check of all was well.

That’s quite easily done, using a unit test. It’s ever so simple, but helps you to check the object model while designing. Just make the test project your current project, add a reference to the assembly that holds your XPO model (everyone puts that in a separate assembly, right?) and run the test when you want to check your model.

This is the single line test that has been my friend for today:

[TestMethod]
public void CheckValidityOfDicationary()
{
    new ReflectionDictionary().GetDataStoreSchema(typeof(S7XPO_Base).Assembly);
}

Replace S7XPO_Base with any of your persistent classes and you’re off. If there is an error, an exception is thrown and your test will fail, telling you exactly where the problem is.

Hope this is of use to anyone. It certainly helped me a lot.

Bye,

Bart