chore: Fix non-string state variable serialization

[JamesBurnsCanva]

Problem I encountered

When using the Java DSL, I was experimenting with state variables.
I used InStateWithVariables like so:

var placeholderId = "some_id";
var placeholderCost = 123;
new InStateWithVariables(
  "a product exists",
  Map.of("id", placeholderId, "cost", placeholderCost))

In my IndividualSuccessTestConfigBuilder.withTestResponse, I found found the following problem:

.withTestResponse(
  (response, setupInfo) -> {
    // This check works
    assertThat(response.id).isEqualTo(setupInfo.getStateVariable("id"));
    // This check doesn't. State variable value is "", expected "123", fails parseInt
    assertThat(response.cost).isEqualTo(Integer.parseInt(setupInfo.getStateVariable("cost")));
  }
);

Cause

In the gRPC layer, you assign set the value of a StringValue to the mapper state variable value. The value inside Contract Case is an integer. StringValue can't take integers, and sets its value to "" if you try.

Fix

Map the values to strings.

Note

The mock value right next to this also remains unmapped. This didn't affect me and I don't know anything about the mock field, so I didn't touch it, but it's possible that is a similar bug. If so, you might wanna fix that too.

[TimothyJones]

Thanks for this! This is a hold over from when state variables were only strings.

However, I think it would be better to serialise all things to json, not just non strings. This matches the behaviour of the other cross-language communication.

Also, because this fix is directly in the internals layer, I believe this fix will break javascript clients. It's possible we don't have a test that covers it.

Either way, I'll sort this out and get it released.

[TimothyJones]

However, I think it would be better to serialise all things to json, not just non strings. This matches the behaviour of the other cross-language communication.

The other reason for this is that otherwise you can't tell the difference between a string that is "123" and a number that is 123 which got serialised to string as "123".

[TimothyJones]

Thanks for this. I'm releasing a new version now. It won't pass your test of:

Integer.parseInt(setupInfo.getStateVariable("cost"))

because getStateVariable(name) is still only for strings (to keep the existing behaviour). What I've done is:

• deprecate getStateVariable(name)
• add getStateVariable(name, Class), for arbitrary deserialisation
• add getStringStateVariable(name) and getIntegerStateVeriable(name) convenience functions