Rinat Abdullin

I’m really “deep in the trenches” right now due to two concurrent projects running. Nonetheless, here are just some quick notes:

• Avoid using DevExpress XPO for large-scale projects where the future requirements could change. It is extremely easy to get started with that, but in the long term your DAL could become a bottleneck in the process of the project evolution (flexibility is too limited).
• Do not use XPO 2 Linq! It supports only basic queries and has absolutely no documentation/matrix/test suite to validate and tell what’s working and what is not. Test suite of NHibernate 2 Linq is something I would expect to find in such a product.
• There is another option for the single gateway interface (as in DevExpress XPO) utilized by xLim projects. That’s the WCF 2 Linq project or any other analogue (there surely be more of these as the technology gets adopted).
• Some say that the combination of Final Builder and TeamCity is the most flexible for the integration purposes. Well, this could be true - FB even has tasks to deal with VMs.

Inspired by the abovementioned NHibernate 2 Linq test suite (it utilizes the power of MBUnit) I recently implemented a nice business test suite for the xLim2-2 application. Basically this is the test suite that re-uses connectivity and logic modules implemented with the help of Autofac IoC container (simple config is used to get them setup and running). The initialization happens in the global setup routine (supported by MBUnit). And then the actual tests just resolve some components/services from the main container (every test is running within its own container scope) and run simple assertions around these.

Example of an assert could be - “make sure that there are no critical errors in the system log”, “make sure that loose object references in the database point to each other” or “make sure that file store is in consistent state with the DB”.

So, provided you have the proper config and the compiled unit test, you just can point it to any production system and check its status in simple manner.

If we take the idea further, then these tests could be uploaded to the CruiseControl.NET to let them run against production on a schedule. And if something breaks - you’ll get the notification immediately (CC.NET will handle that).

Additionally it is easy to set up continuous statistics capturing via the same tech. So we get continuous system validation here and continuous system monitoring at the expense of writing just some validation tests and doing one-time setups.