As I’m moving the OpenWFE circus to 1.7.0, I removed some awful hacks from the expressions and of course I’m now testing this intensively.
(well, they were not that awful, they made sense in their time, but now, the code is simpler).
OpenWFE is released with a CachedExpressionPool by default, it means that the engine keeps in memory (cache) a certain number of expressions (pieces of workflow instances) for direct usage.
I’m currently testing with a SimpleExpressionPool, no cache : everything is persisted (to the filesystem, as by default). It rose a certain number of bugs (4) that I’m currently fixing.
From now on it will be imperative to test OpenWFE with the cache and without it. Testing without cache shows really if all the expressions are persisted perfectly. For a tool that has to enact long lived processes this is crucial.
I figured out I might write some lines about how OpenWFE core is tested.
There is a complete test suite for OpenWFE. It’s written in Python, taking advantage of openwfe-python, the Python ‘connector’ to OpenWFE.
It’s a set of Python scripts enacting various processes and behaving like users and participants of these processes. Using a scripting language to test OpenWFE proved very flexible.
Lately, there has been a new breed of tests added, they are written in Python too but each of them triggers a lightweight embedded OpenWFE engine, pipes a process definition into it and controls the output (stdout).
I’ll perhaps write the next of those ‘pipe’ tests in Ruby, which I really like, having written openwfe-ruby from Costa Rica. Coding in Ruby (and Python) is fun.
There are no ‘unit tests’ in java for OpenWFE, the test suite challenges the whole stack. Well, the ‘pipe tests’ do somehow resemble ‘unit tests’ as they test small aspects of OpenWFE (mainly expressions).
OK, I stop writing and I get back to the code, OpenWFE 1.7.0 is due soon.