For teams with a test that passes and fails with no code change, or a suite that went red after a planned UI change.
Your setup
- A Playwright, Cypress, Selenium, pytest or similar suite in a GitHub repo.
- A test environment the tests can run against, with the current UI deployed.
- You review every change as a pull request.
Say this to Certyn
For a flaky test:
The "apply coupon" test in acme/web is flaky. Find out why and fix it in a PR.
After a UI change:
The new checkout design (PR #412) broke about 30 tests in acme/web. The change is intended. Update the tests in one PR.
What Certyn does
- Opens the
GH_TOKENform if needed: Contents and Pull requests, Read and write. - Clones the repo and runs the tests against the environment, with the same settings as your CI.
A flaky test:
- Runs the test many times in a row (for Playwright,
--repeat-each). - Compares passing and failing tries: traces, screenshots, timing, test data, test order.
- Names the cause, for example a click before the page is ready, data shared between tests, or a fixed wait.
- Makes the smallest fix on a
certyn/...branch, such as waiting for the right element or giving the test its own data, then runs it many times again.
A UI change:
- Reads the UI change you named, so it knows what changed on purpose.
- Sorts each failure: broken test (old selector or text), product bug, flaky, or setup.
- Fixes broken tests at the source. A locator in a shared page object or helper is fixed once, not in 30 files. It uses the locator style your suite already uses (roles, test ids, or text).
- Runs the fixed tests again on a
certyn/...branch.
Then it opens one pull request with the cause, the changes and why, and the before and after results.
What you get
- One pull request with the fix and the proof.
- A run report with what was fixed and what still fails.
- If the app is at fault (for example a button that sometimes submits twice), a finding with evidence, not a test change. Ten tests that fail on one broken page are one finding.
Limits
- Certyn never makes a test pass by weakening it: no removed checks, no retries added to hide the failure, no larger timeouts as the only fix. A test whose flow no longer exists is listed in the PR for you to decide.
- Certyn cannot know by itself that a UI change was intended. Name the PR or say the change is intended. Otherwise a missing button is a product bug and is reported.
- Some flakes appear only under CI load. If Certyn cannot make the test fail in many tries, it says so and does not guess a fix. Share a CI trace, or run it on your runner.
- One shell command on a Machine can run 30 minutes. Longer loops run in the background, or as a run of up to 4 hours. Certyn asks before it uses more time.
- Certyn never merges.
- For Certyn's own test cases (not code in your repo), type
/flakyin the chat, or see Keep the suite healthy.