Interactive console for debugging

Dear Camunda community,

I would appreciate your sharing of the debugging strategies / tweaks you use during the development (non-Java). Looks like build-debug-rebuild cycle is very time consuming, so any suggestions to improve it are more than welcome.

Is there anything like an interactive console for process engine existing in the wild? I.e. any script interpreter running in a process engine context, so it gives a developer a way to interactively test code snippets, etc. Alternatively a REST end point to receive commands emulating service task and sending back results of the execution?

Thank you in advance.

Best regards,
Ilya

Write a script based unit test: https://github.com/DigitalState/Camunda-Spock-Testing

Examples are provided for testing nashorn all by itself or as part of the overall process.
At each wait state in the process you can do a println on the current variables in the process and you can assert your expectations. All examples are provided with inline code commenting.

Hi @StephenOTT,

Thank you for your suggestion. Agree that unit testing and E2E tests are very important. However to start testing you need to have some code to test :wink: For dumping variables we use a simple js script @ execution listeners (start or end). I believe the key thing is to have some interactive environment to experiment in camunda’s context.

At the moment I do such experiments via creating a simple one activity process, deploying via REST API, running interactively in a tasklist or via REST API and dumping results onto console. However it is far from being truly interactive. Usually, it is possible to run around 100 cycles per man-day this way…

Best regards,
Ilya

Take a look at the repo and the specific tests that are nashorn based. These are the equivalent to you running a script with a execution listener (but using the script based tests are faster). The point of the scripting unit tests is to use a Scripting language to write the test, and within that test you are generating another scripting env (the nashorn engine) and executing the tests within it. Ignore the fact that it is “unit testing” and specifically look at the examples of what is going on; you can have a single task process that executes a js file based script and you return the output.
All of the problems you describe as well as the “process” you describe of manual deployments were a reason for the spock unit testing pattern was created.

Hi @StephenOTT,

Will take a look! Thank you

Best regards,
Ilya

Any luck? @Ilya_Malyarenko

Hi @StephenOTT,

I experimented with your examples of Spock test cases. It seems to be an interesting approach in general for testing in camunda for non-Java developers (or even Java developers), but I would not (personally) think of it as of an ad-hoc interactive debugging alternative. The Spock overhead (test spec) is quite heavy.

I might consider Spock as a test framework for our project.

Best regards,
Ilya

What do you mean by overhead ?

Hi Stephen,

Well, the specification itself and some additional steps like mocking of execution context. Again, this is my first impression and I haven’t worked with Spock before.

Best regards,
Ilya

The mocking of execution is only needed when you are executing some script that you don’t want to test inside of the actual engine instance.

Look at the end to end example for the process engine: https://github.com/DigitalState/Camunda-Spock-Testing/blob/master/End-to-End/src/test/groovy/end-to-end/EndToEndSpec.groovy

@Ilya_Malyarenko
I have updated spock examples with a “interactive” example: https://github.com/DigitalState/Camunda-Spock-Testing/tree/master/interactive-example

Go into the interactive-example folder and run ./mvnw clean test

the “magic” will be lines like this:

where all of the variables in the active process instance are printed to the console.

you console printout looks like:

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running InteractiveSpec
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
May 29, 2018 9:41:33 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [camunda_config/camunda.cfg.xml]
Deployment ID: '1' has been created
Starting the process instance
Process is Active and waiting for user task completion
Process Variables are:
['someVar':'Some String Value', 'json':{"customer":"Kermit"}]
Deployment ID: '1' has been deleted
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.233 sec - in InteractiveSpec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 22.290 s
[INFO] Finished at: 2018-05-29T21:41:47-04:00
[INFO] Final Memory: 22M/179M
[INFO] ------------------------------------------------------------------------

I have updated the InteractiveSpec.groovy file with simplifications and additional code comments. You don’t need to do much other than duplicate the existing example.
All of the engine services are exposed as per the camunda junit docs (runtimeService(), repositoryService(), taskService(), formService(), etc).

In the example you will see there is a usage of a external script file as well deployment://script1.js.

You can easily make code changes in the BPMN and .js files, and quickly rerun the tests.
If you connect this up to eclipse or intelliJ you can have the tests auto run as you make updates (but not required).

Note: The test/spec is setup the way it is so you can easily copy and paste to create more complex test/interactive scenarios like running multiple BPMNs that have wait states, external files, templates, etc, and preforms end to end operations (like cleanup at the end (but this is commented out for simplicity)), so you can pretty much just copy and paste from the examples to preform 99% of the typical scripting scenarios.

Also notice how it is mvnw rather than mvn. This is because the maven wrapper is installed in that folder, allowing you to do ./mvnw clean test as the command. This helps so you do not need to install mvn on the machine running the test/“interactive” output