# Wildcard vs. Fixture Refactor: Asserting Evolving API Schemas in Karate

In Karate 1.x, the match keyword provides a # wildcard that tolerates unspecified fields in API responses, allowing limited schema change tolerance without test failure. However, when a new required field is introduced, the same match block fails, indicating the need for manual updates. The call and callonce mechanisms reduce duplication by reusing request and response fixtures, which can mitigate drift when schemas evolve across multiple test files. Despite these documented features, Karate does not automatically version or migrate expected JSON schemas when the API contract changes, leaving the choice of assertion strategy to test authors. This creates a practical constraint: balancing schema tolerance against fixture maintenance as the API surface grows.

Does relying on the # wildcard in match assertions risk masking breaking changes in downstream API versions? When should a team restructure fixtures via call/callonce versus accepting wildcard tolerance for evolving schemas? How does Karate version affect the reliability of wildcard matching in complex nested JSON structures?