In order to make the next version of RobinVOL more robust and portable, we are putting special emphasis on delegating on an external library as much workload as we can. This will make expanding to new platforms easier in the future, amongst other benefits. We should mention that the only thing that can not be done externally is the actual communication with the broker.

One benefit of focusing on an external library is that knowing most of the logic is done there, we can easily add new functionality through a test-driven development process. The main advantage of this is it being an iterative process: after some tests have been done and passed, we will be able to modify existing code knowing that, if we mess up at some point, those function tests are likely to fail.

Catch is the test framework we decided to work with, given its easy-to-use yet flexible testing capabilities. For the actual tests, we are focusing on making a battery of small tests for each function, rather than making a set of unique huge complex tests. There are two main reasons for taking this approach: First, the programmer can easily check what a test is actually doing: if tests get too big, they may become a headache for the programmer in case a variable has been initialized to another value by mistype, for example. The other reason is that this way is easier to isolate and test a function for extreme, impossible, or whatever input we want.

Currently, an average of 9 tests are being done for each function (126 tests for 14 functions). This value is not too high, but since we are still in the developing phase and the code is subject to many changes, we do not want that value to rise more, since a modification in the global structure could force us to rewrite a lot of tests.

For designing our tests, we are following a bottom-up approach: we are first designing tests for our smaller functions in which the big ones rely on. This way, it will be easier for the programmer to spot possible bugs for them in the future. So as of now, all functions we are testing do not have too much functionality by themselves, but they represent the core of the RobinVOL algorithm.

In conclusion, testing our code plays an important role in the development of RobinVOL, specially when sensible changes are made, such as rewriting a data structure.