reversa-inspector

To prove behavioral parity, you need to establish equivalence criteria and generate executable Gherkin specifications for critical legacy flows. This approach validates that the migrated system behaves equivalently where it matters, even when the execution paradigm changes.

You generate Gherkin specs for migration acceptance testing by creating parity scenarios for each critical flow, outputting them as .feature files. These executable specifications allow a downstream coding agent to map them into the correct test framework.

Handling UI parity validation during screen modernization depends on the configured mode: use visual golden-file comparison for literal parity, contract-oriented scenarios for modernized parity, or skip UI parity validation entirely when not applicable.

Migration parity testing does require additional coverage when changing execution paradigms. You must expand validation to include paradigm-specific dimensions like idempotency, message-order semantics, invariants, immutability, and supervision to ensure true behavioral equivalence.

Before generating parity specifications for a legacy system migration, you need to read the migration SDD prerequisites, select validation modes, and define primary acceptance metrics. These inputs drive the generation of the parity specs and test scenarios.

You cannot execute runtime parity tests directly from the generated Gherkin feature files. They serve as executable specifications that define acceptance criteria, requiring a downstream coding agent to map them into the appropriate runtime test framework.