Hi folks,

I have a somewhat complicated process definition, most of which is
comprised of putting the workitem in a StorageParticipant and waiting
for a human user to do something to it (via a web interface). The
problem I'm running into is in testing: as I test the deeper parts of
the process, my tests become slower and slower. Since Ruote is
asynchronous, I have to sleep the test process, and as the tests go
deeper, the sleeps build up into unacceptable lag.

For instance, in a simple case, I might do something like "launch,
sleep(0.1), interact, sleep(0.1), test". Of course, to test an
interaction three steps down in the process tree, there are 4 sleeps
required. Further aggravating the issue, the required sleep time isn't
consistent across development machines (or even on the same machine),
so I usually find I need to sleep for 0.2 - 0.5 seconds *per step* in
order to have consistent results.

I've tried Engine#wait_for, but none of the options work for me:
passing a wfid won't work because the process isn't terminating,
passing a participant just hangs the test process indefinitely, and an
integer won't work because I've no idea how many messages need to be
passed.

I see two potential solutions:

1. some way to "jump" the process instance to a given state, kind of
like stubbing or database fixtures
2. some way to reliably detect and respond to engine events,
effectively making my tests run synchronously with the engine (ie. get
#wait_for working)

Unfortunately, I've no idea how I would approach either solution. Are
there other solutions? Help approaching one of these?

Thanks,
Ian

-- 
you received this message because you are subscribed to the "ruote users" group.
to post : send email to [email protected]
to unsubscribe : send email to [email protected]
more options : http://groups.google.com/group/openwferu-users?hl=en

Reply via email to