camunda / camunda-bpm-assert Goto Github PK

• Implement/Review
• Test Systematically
• Document

Its out long enough, so the next release could use 7.1 as a base.

Something like deploy(String... resource) would be quite helpful for test frameworks which can't work with the @ Deployment annotation out of the box.

TaskAssert misses a check for assigned candidate user. Similar candidateGroup assertion exists.

Due to the size of the current README.md, we should not add the CMMN stuff to it.

Proposal:
/camunda-bpm-assert/README.md contains genric things and links to
/camunda-bpm-assert/README-BPMN.md and
/camunda-bpm-assert/README-CMMN.md

Also, the README-CMMN.md should incorporate and replace CMMN.md.

we still use 1.5, there is a new version out. Didn't check the changelog, but it wouldn't hurt to use latest in the next release.

similar to ProcessEngineNeedleRule / assertNoMoreRunningInstances

We could maybe add the possibility to send the message easily like with complete(task())

see comment at http://blog.camunda.org/2014/03/camunda-bpm-assert-10-released-as.html

Since the now called "*-core" module (jar) is the only module I would really want to import in my test-scope, I'd suggest shifting the naming from

assert
+- assert-core
+- assert-examples

to

assert-root (or -parent)
+- assert
+-assert-examples

This way, I don't have to know the projects internal structure to just use the dependency, its camunda-bpm-assert and nothing else.

If a process instance is ended it should be possible to query at least the latest value of a process variable.
I think it would be OK to do that internally in the "variables()" assert - just return the map of HistoricVariableInstances if a ProcessInstance is ended. Or create a new "historicVariables()"?

We should use the same terms within the camunda repositories and "parent" is more common than root and also correlates better with the maven multimodule concept.
Thus +1 for camunda-bpm-assert-parent.

as version 1.1 - next dev version is 1.2-SNAPSHOT - many thx!

strangly that one is missing ... though the business key is accessible via get() on the process instance.

Currently isWaitingExactlyAt() sorts the provided activityIds but the activity returned by the database might not have the same order.

See #44 to reproduce issue and possible fix.

• Implement/Review
• Test Systematically
• Document

comparable to what is possible with task() and job() - as processes might have sub processes via call activity

Once we switch to 7.1 we should have everything together to publish on mvn central which would spare the users the extra efford of registering an additional repo.

• multiple builds based on different camunda BPM versions
• anonymous read access to CI server
• link in README file

As a new contributor, I need to know all design decisions + reasoning, in order to provide good contribututions.

A colleague working with the assertions in our new project just came to me because he was confused by an assertion error message.

He was using "assertThat(processInstance).isWaitingAt("foo")", but accidentally modelled a "Task" instead of a "UserTask". So the execution had not wait state and the test failed.
So far so good. But, the message he got was:

   "Expecting assertion to be called on non-null current state of actual %s, "but found it to be null!"

This happens because of the "A getExistingCurrent()" method called before the isWaitingAt assertion.

I believe, a simple "the process instance already ended" would be clearer here, helping to find the real bug - wrong task type.

Thanks.

This appears to be a problem in camunda-bpm-assert rather than in the engine.

The method TaskAssert#hasCandidateGroup makes the following query:
taskQuery().taskId(actual.getId()).taskCandidateGroup(candidateGroupId).singleResult();

The javadoc for TaskQuery#taskCandidateGroup says:

Per default it only selects tasks which are not already assigned to a user. To also include assigned task in the result specify {@link #includeAssignedTasks()} in your query.

So, the query you need is
taskQuery().taskId(actual.getId()).taskCandidateGroup(candidateGroupId).includeAssignedTasks().singleResult();

Are you sure that this worked with 7.2? Because the null check for assignee when filtering by candidate group appears to be there for quite a long time already.

Cheers,
Thorben

Since we have to init and reset every use of the Assertions anyway, it would be nice to have a rule (TestWatcher or external resource) that takes care of this via before/after.
With junit 4.11 this rule can then easily be chained with other rules (processEngineRule, needleRule) to orchestrate test behavior.

in case neither a default engine was found nor init() was called before. Instead an IllegalStateException should be thrown.

• Assumedly ProcessEngines.getDefaultProcessEngine must be called with forceCreate = false
• To be considered: use the only process engine available in the process engines map, if there is only one...

In parallel to existing mechanism for Tasks.

Similar as for running process instances and their intermediate (message and signal) events, it should be possible to check whether process definitions wait for messages or subscribe to signals in order to create instances at start events.

Currently the isWaitingFor/isNotWaitingFor assertions just support the message name. It would be meaningful to also support a check for the existence of specifically expected correlation keys (business keys, process instance variables)

Background: enable testing frameworks which don't rely on assertions which directly throw an AssertionError - like e.g. the Spock Framework

Most methods there simply delegate to other classes. Can be tested and documented in one issue.

I wanted to get an assertion error that states that my expectation about the state of the current process is false, like "expected processinstance 9 to be waiting at "foo", but was "...".
Instead I got "actual must not be null", so the task "foo" was not found and the assertion just went on, failing with a very hard to read error message.

Wish: Make assertThat(processINstance).task("foo").isXXX() fail with "not waiting at task "foo"" when the task is not active.

Since we have several community extensions addressing testing, I think it s a good idea to group them all under the id:

org.camunda.bpm.extension.test

Hello,

could you please release the sources jar also.

They are not available here:
https://app.camunda.com/nexus/content/groups/public/org/camunda/bpm/extension/camunda-bpm-assert/1.0/