Regenerate a Test
Regenerate when the generated output does not match the behavior you intended, or when the feature changed.
Regeneration is most effective after you improve the inputs. Re-running generation without changing anything often produces the same kind of problem.
Review the previous output, fix the Gherkin or setting that caused the problem, save, then regenerate and watch the fresh attempt through to code you can run.
Good Reasons To Regenerate
| Reason | Example |
|---|---|
| You edited Gherkin | Added clearer steps or a stronger assertion. |
| The app changed | Labels, pages, or behavior changed since the last generation. |
| The output missed the intent | The generated code clicked the wrong thing or skipped a result. |
| Setup was fixed | API key, secret, site URL, or test data is now available. |
| Generation failed | You addressed the failure and want another attempt. |
Before Regenerating
Review the previous output and decide what input needs to change.
| Problem | Improve this first |
|---|---|
| Wrong page or flow | Starting context and target site URL. |
| Weak assertion | Then steps and expected visible outcomes. |
| Missing login or setup | Background, explicit setup steps, or secrets. |
| Wrong UI element | Visible labels, button names, field names, or role descriptions. |
| Run failed before generation | API keys, project access, or session configuration. |
Steps
- Open the feature in Tests.
- Review the previous generation details if available.
- Edit the Gherkin or project settings that caused the issue.
- Save the feature.
- Start generation again.
- Watch progress.
- Review the generated output before running.
Use … → Regenerate after saving. If the previous generation failed, its result may offer Retry. A fresh attempt shows its own activity; old results do not mean the new attempt has completed.
What Might Be Replaced
Regeneration can update generated Playwright files. If your team manually edited generated code, those edits may be overwritten or need to be reapplied.
Before regenerating, consider:
- whether manual code changes should be moved into clearer Gherkin
- whether the code change belongs in a reusable helper
- whether the generated file should be reviewed after regeneration
After Regeneration
Run one test first. If it passes, you can run the group or suite.
If it fails, inspect the result evidence. A failed run can mean:
- the app has a real bug
- test data is missing
- the generated code still needs improvement
- the site or session setup is wrong
For result review, see Inspect failed steps.