Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose expected fields in AssertMatchOperator #200

Open
b-hodge opened this issue Oct 23, 2024 · 0 comments
Open

Expose expected fields in AssertMatchOperator #200

b-hodge opened this issue Oct 23, 2024 · 0 comments

Comments

@b-hodge
Copy link

b-hodge commented Oct 23, 2024

Is your feature request related to a problem? Please describe.
The AssertMatchOperator is a very useful tool for applying custom validation logic to particular fields in a result. However, the current implementation exposes only the actual result values, instead of also exposing the expected result values. This makes it difficult to perform validations that use the expected value, but are not just strict equality comparisons.

A simple example of something that's currently difficult to do: Verify that a given field in a result has the same first N characters as the corresponding field in a snapshot file.

Describe the solution you'd like
ExecuteMatch in AssertMatchOperator already has access to an expectedSnapshotData, it just doesn't do anything with it. I'd like to be able to define an assert function that takes both actual and expected field options and performs assertions across the two.

Describe alternatives you've considered
It's possible to implement this sort of logic in test code rather than using Snapshooter directly, but that loses many of the things that make Snapshooter so useful, like automatic mismatch handling.

It's also possible to do something similar using the existing AssertMatchOperator, but that requires maintaining a source of truth for expected values that's separate from the existing .snap file.

Additional context
This seems like a simple change. I'm happy to make it myself, but perhaps the maintainers here would prefer a different approach for solving this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant