Copper unit tests, best practices.

48 views
Skip to first unread message

Alex Shubert

unread,
Oct 23, 2016, 4:05:51 AM10/23/16
to COPPER Engine
Hello everyone.
After implementing some flows I've faced some issues in which I need your advice.
1. So, what is the best way to test flows? Is there any special approach, best practice except mocking everything and everyone and testing the calls?
2. How do I get all active flows? How to monitor them?

Thank you.

Michael Austermann

unread,
Oct 24, 2016, 3:25:54 AM10/24/16
to copper...@googlegroups.com
1.
You know, you can run persistent workflows also in a transient engine.
So I would create a transient engine, e.g. using org.copperengine.core.tranzient.TransientEngineFactory and use mocks in the workflows.
If you want to make sure, that all the data in your workflows is really serializable, but you don't want to use MySQL, Oracle or Postgres for your tests, you can also create a peristent engine with an in-process derbydb or H2. 
org.copperengine.ext.persistent.RdbmsEngineFactory might be helpful.

2.
Check the JMX interfaces, e.g. ProcessingEngineMXBean


Von: "Alex Shubert" <alex.s...@gmail.com>
An: "COPPER Engine" <copper...@googlegroups.com>
Gesendet: Sonntag, 23. Oktober 2016 10:05:50
Betreff: [COPPER Users] Copper unit tests, best practices.

--
You received this message because you are subscribed to the Google Groups "COPPER Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to copper-engin...@googlegroups.com.
To post to this group, send email to copper...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/copper-engine/31962315-88ea-4328-a24c-2f0de5cb1461%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Alex Shubert

unread,
Oct 24, 2016, 4:40:28 AM10/24/16
to COPPER Engine, michael.a...@scoop-software.de
Hello!
First of all, thank you for the response. 

Yes, this is what we did here, we mocked crucial parts and services. However, what still disturbs me is the `Thread.sleep` in our code. Is there any way notify test that flow in subject went in another `wait` or just received an event? 

It seems that `PersistentProcessingEngineMXBean` is exactly what I was looking for, thank you! 

Dirk Möbius

unread,
Oct 24, 2016, 5:35:38 AM10/24/16
to copper...@googlegroups.com
Hi Alex,

> However, what still disturbs me is the `Thread.sleep` in our code. Is there any way notify test that flow in subject went in another `wait` or just received an event? 

I assume what you want is to be notified whenever a COPPER workflow changes state (ie. is started/finished or goes into wait). Currently there is no such possibility. What you could do is poll the database table COP_WORKFLOW_INSTANCE until the record for your workflow instance is either removed or in a state != 2. However, this is polling, and you still need Thread.sleep().

We could add a listener (observer) interface to ProcessingEngine for such usecases. If you want it, please file a feature request at https://github.com/copper-engine/copper-engine/issues

Best regards,
Dirk

Alex Shubert

unread,
Oct 24, 2016, 6:39:09 AM10/24/16
to copper...@googlegroups.com
Hi, Dirk 

Nice idea, polling db in test is better than waiting with unpredicted outcome (who knows how long async could take, right?) so I am going to adapt that approach. 
I'll fill feature request.
Have a nice day. 


On Mon, Oct 24, 2016 at 12:35 PM, Dirk Möbius <dimo...@gmail.com> wrote:
Hi Alex,

> However, what still disturbs me is the `Thread.sleep` in our code. Is there any way notify test that flow in subject went in another `wait` or just received an event? 

I assume what you want is to be notified whenever a COPPER workflow changes state (ie. is started/finished or goes into wait). Currently there is no such possibility. What you could do is poll the database table COP_WORKFLOW_INSTANCE until the record for your workflow instance is either removed or in a state != 2. However, this is polling, and you still need Thread.sleep().

We could add a listener (observer) interface to ProcessingEngine for such usecases. If you want it, please file a feature request at https://github.com/copper-engine/copper-engine/issues

Best regards,
Dirk


--
Best regards
Alexandr
Reply all
Reply to author
Forward
0 new messages