test: assert quotations for string variables

[barinali]

Proposed Changes

This pull request aims to provide red test coverage for the #88 as the current tests are false positive.

Checklist

Ensure you provide everything we need to review your contribution:

• Contribution meets our definition of done
• Pull request establishes context
  • Link to related issue(s), i.e. Closes {LINK_TO_ISSUE} or Related to {LINK_TO_ISSUE}
  • Brief textual description of the changes
  • Screenshots or short videos showing UI/UX changes
  • Steps to try out, i.e. using the @bpmn-io/sr tool

[Copilot]

Pull request overview

Adds stricter test assertions to ensure string variable info values are consistently serialized with surrounding quotes, addressing false-positive coverage related to #88 (inconsistent string serialization).

Changes:

• Update ZeebeVariableResolver specs to assert quoted info for string literals, static inputs, and path-resolved string values.
• Update mapping specs to assert quoted info for string-typed primitive entries and script/output mapping results.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
test/spec/zeebe/ZeebeVariableResolver.spec.js	Tightens assertions for string info quoting across static inputs, literal outputs, and path expressions.
test/spec/zeebe/Mappings.spec.js	Tightens assertions for string info quoting in primitive mapping results and scope/mapping scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[Copilot]

These assertions change the expected info for string variables from unquoted (e.g. YES) to quoted (e.g. "YES"). Since this PR only updates tests (no corresponding serialization change in the resolver), this will make the existing test suite fail unless the implementation is updated in the same PR or the tests are explicitly marked as pending/red (e.g. it.skip) until the fix lands.

Suggested change

	{ name: 'staticInput', type: 'String', scope: 'ServiceTask_1', info: '"YES"' },
	{ name: 'otherStaticInput', type: 'String', scope: 'ServiceTask_1', info: '""YES""""' }
	{ name: 'staticInput', type: 'String', scope: 'ServiceTask_1', info: 'YES' },
	{ name: 'otherStaticInput', type: 'String', scope: 'ServiceTask_1', info: '""YES""' }

[Copilot]

The expected value for otherStaticInput (""YES"""") is very hard to read and easy to get wrong when adjusting tests later. Consider factoring this into a clearly named helper/constant that documents what is being asserted (e.g. raw-value-wrapped-in-quotes vs escaped FEEL literal), so the intent of the quoting behavior is unambiguous.

[Copilot]

These updated expectations require string info values to include surrounding quotes (e.g. "foo", "1"). If the resolver still derives info from the raw atomic string value, these tests will fail without a matching implementation change; consider pairing this with the serialization fix in the same PR (or marking the tests as intentionally red/pending).

[barinali]

<zeebe:input target="otherStaticInput" source="&quot;YES&quot;&quot;&quot;" />

is the input variable definition of otherStaticInput. It has the source of "YES""". There are already quotations in the source/value itself, but now, we want to wrap the value in quotations for the sake of string representation.

I am somewhat confused with the assertion here. So, I'd like to hear your opinions. @nikku @barmac

Is ""YES"""" what we really expect here?

ref: #88 (comment)

[nikku]

I expect the FEEL / JSON representation - which is "\"YES\"\"\""

Cf. playground.

[barinali]

Even though it's a static assignment, we want to serialize it as if it's JSON?

[nikku]

What matters for the user is how it arrives in the engine - at run-time. There it is a string value, no matter whether dynamically computed = "HELLO" or statically configured HELLO. In both cases, it turns to the string "HELLO" at run-time.