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

Application Architecture Guide 2.0

http://apparchguide.codeplex.com/

I am in the middle of redesigning our software and was thinking through some major parts of our software design. We notice the number of clients grow, the size of the companies that uses our software gets larger (Microsoft, SAP, Google, Unit4Agresso, Shell are all companies that use our software) and the number of topics in the Sevensteps projects increase. Our software was designed for documentation projects of around 5000 topics per project (we have projects that are over 400.000 topics in size, but performance is an issue there) and I want to redesign (part of) our software to accommodate larger projects.

Another reason for redesigning is that we currently support one rich client interface. And I want to extend that with a content API (which will give access to the information from, let’s say, an ASP.Net application) and some light weight, web based interfaces. Some other parts of the software could do with a looking over too.

Going all over the net for some background information, I stumbled on the Microsoft Application Architecture Guide 2.0. I’ve now read the first 2 chapters and already got some very valuable information. I find that most things discussed, I already know about and have some experience with. But, to see them listed helps a lot.

I will be reading the next 300 pages or so to see how the topics are elaborated on. I’m not a very keen IT book reader, but will make an exception this time. Anyone looking for some guidance in designing (Microsoft based) software might find it a valuable resource too. If after reading I think a follow up is required, I will do so of course.

Bye,

Bart