Skip to content

Correct edge cases in mappings, adding property-based smoke tests to verify#103

Open
jonathonherbert wants to merge 7 commits intojsh/data-based-specs-for-position-testsfrom
jsh/correct-mappings-like-really-correct
Open

Correct edge cases in mappings, adding property-based smoke tests to verify#103
jonathonherbert wants to merge 7 commits intojsh/data-based-specs-for-position-testsfrom
jsh/correct-mappings-like-really-correct

Conversation

@jonathonherbert
Copy link
Collaborator

@jonathonherbert jonathonherbert commented Nov 22, 2025

(Split from #99 to make the test-based changes easier to review.)

What does this change?

Corrects some inconsistencies in the mappings we generate to map between queryStr and ProseMirror documents. These do not cause problems at the moment, but reveal themselves if we rely on mappings to determine where suggestions should appear, as in #99.

Problems with mappings have historically been difficult to spot and debug. This PR adds tests that use ProseMirror's test builder classes to add markers at the beginning and end (or, in the case of empty nodes, the empty content position) of nodes, which correspond with markers added to a query string. So, for example, we expect the positions given in the angle brackets below:

queryAndPositions: "<a>+<b>:<c> <d>",
doc: doc(
  queryStr("<a>"),
  // Empty chipKey
  chip(chipKey("<b>"), chipValue("<c>")),
  // Empty queryStr
  queryStr("<d>"),
),

... to match exactly. This should make it easy to express the structure that produces a failing case.

Because mapping problems have been caused by unexpected combinations of nodes and content, the tests include some property tests based on pseudo-random combinations of nodes and content. This should give us confidence that the mappings are accurate and we've flushed out edge cases.

Finally, we round-trip the mapping from queryStr -> doc -> queryStr, to make sure that positions are reversible.

How to test

  • The tests should pass. Take a look at the new tests. Are they sufficiently readable to give us confidence that the problem has been solved, and that, in the case of future problems, we can easily express the failing case?

How can we measure success?

Confidence that our mapping from queryStr to ProseMirror doc, and vice-versa, is correct.

to make them simpler and more comprehensible ... but although the tests pass, they are not reversible, which stretches my mental model a bit ... I need to understand better why this wasn't a problem before
…which makes the behaviour clearer

I was testing an inverted mapping, making changes unintuitive D:<

Having said that, I'm not quite sure why getFieldValueRanges requires a negative oldSize rather than a positive toSize for its chipValue end, which is something I arrived at via experimentation rather than a complete understanding ... dislike
cleaning up the ranges to remove the odd inversion, and expanding the property-based tests to verify they are correct
@github-actions
Copy link
Contributor

github-actions bot commented Nov 22, 2025

return docToCqlStr(newState.doc);
};

export function* pseudoRandom(seed: number): Generator<number, number, number> {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For deterministic tests.

@jonathonherbert jonathonherbert added the feature Departmental tracking: work on a new feature label Nov 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature Departmental tracking: work on a new feature

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant