Unit Testing: Challenge Accepted

We have mentioned unit testing on Mendix and Beyond before (Test Driven Modelling) and over the past year we have been experimenting with various methods of unit testing and what exactly to unit test. What to test will be for another day though, today we will discuss our latest method for unit testing.

The main unit testing framework we had used to date was to build a structure of test sets, unit tests and test logs which are built and maintained through other microflows. Now unit tests are meant to be simple to construct and maintain and although this above structure provided the ability to build detailed unit tests, particularly with it’s own log structure, as well as a neat way to categorize the tests into a tree of test sets. It was a rather large hassle to build and maintain these tests manually over the long run.

The original Unit Testing Domain Model

So now obviously we have resolved these issues (otherwise why would I be writing this post…)

Well the newer version wasn’t a dramatic leap, instead what we focused on was on removing as much manual building from adding unit tests to libraries, standardizing the tests and making things as quick and simple to do as possible. So with some magic borrowed from MXModelReflection and some brainpower, we moved to the following 3 standards for unit testing microflows:

1. start with ut_
2. take no inputs
3. output is either a string or a boolean

Unit Tests and UT_BooleanError

From this starting point we could have a  microflow find all microflows which fit the above criteria, execute them (through a java action) and store the response as Passed, Failed or Error. (In the case of a string an empty string is a success.)

The One flow to rule them all

With this solution we could now not worry about manually creating test objects within the microflow for result storage, and not worry about wiring it up to the testing framework. Instead a simple rename, compile and execute and all unit testing has been performed. Add in a viewing location, some timing elements, the ability to fire off single unit tests and our unit testing framework is ready to go 🙂

Unit Testing in practice: Run showing failed unit tests and responses.

If you are interested you can download the unit testing project (4.0.1) here. Questions or comments welcome

Now of course I have been doing far too many technical posts compared to my colleagues so be aware that the philosophical posts will be approaching soon 😉