Skip to content

Fix failing tests

Certyn finds why a test is flaky, or updates the tests a UI change broke, and opens one pull request with the proof.

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

  1. Opens the GH_TOKEN form if needed: Contents and Pull requests, Read and write.
  2. Clones the repo and runs the tests against the environment, with the same settings as your CI.

A flaky test:

  1. Runs the test many times in a row (for Playwright, --repeat-each).
  2. Compares passing and failing tries: traces, screenshots, timing, test data, test order.
  3. Names the cause, for example a click before the page is ready, data shared between tests, or a fixed wait.
  4. 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:

  1. Reads the UI change you named, so it knows what changed on purpose.
  2. Sorts each failure: broken test (old selector or text), product bug, flaky, or setup.
  3. 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).
  4. 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 /flaky in the chat, or see Keep the suite healthy.