Add two new methods to ReceiveMessageBuilder in the Java DSL: validateXpath and validateJsonPath, which accept Maps as arguments.

[tvelkoff]

I propose to add two new methods to ReceiveMessageBuilder in the Java DSL: validateXpath and validateJsonPath, which accept Maps as arguments. (see lines 585-604)

Here is the motivation... I have many test cases similar to this:

designer.soap()
  .client(this.client)
  .receive()
  .schemaValidation(false)
  .validate("//lexs:ResultCode", "Success")
  .validate("//lexs:SearchResponseMetadata/lexs:MaxItemMatchesRequested", "10")
  .validate("//lexs:SearchResponseMetadata/lexs:NumberItemMatches", "10")
  .validate("//lexs:SearchResponseMetadata/lexs:ServerLimitIndicator", "true");

where the only difference is a variable number of assertions. What motivates the need for the new methods is the desire to create a single method in my test code that eliminates redundancy in individual tests, like this:

protected void runTest(TestDesigner designer, String inputPathString, Map<String, Object> assertions) {
...
  designer.soap()
  ... (as above)
  .validate(assertions); <--new method used here
}

I found no test cases for this class and therefore created a JUnit 5 test class that covers the public methods as well as the two proposed new methods. There are four tests I left in Disabled state - I was unable to get the desired outcome using Mockito.

There are two other code changes that are unrelated, and that could be rejected or deferred. getScriptValidationContext throws a NullPointerException if messageType has not previously been called. For this I added an assertion similar to those on some other methods.

A couple of methods related to headerFragment proved difficult to mock and test because a StringResult is created inside the method. I introduced helper methods that could be called by the unit tests, but left the existing public method signatures unchanged. These methods delegate to the helpers. Again, these changes were introduced only to facilitate unit testing.

As directed, I've created this issue in relation to this pull request: citrusframework/citrus#567

[svettwer]

Hi!

I like the idea. This makes the API a little bit more flexible in my opinion. I briefly checked the rest of the API and found two similar implementations in the ZooActionBuilder and KubernetesActionBuilder. We should add a map variant there as well to extend the API consistently.

BR, Sven

[svettwer]

Ah! :man_facepalming: I just realized that the kubernetes and zookeeper module are both low priority modules. Therefore I wont extend them with the new API.

BR, Sven