Skip to content
Start Free

Write tests for new work

Certyn writes tests for a new feature or for what each merge changed, in your team's style, runs them, and opens a pull request.

For teams that ship features faster than they write tests, and want new tests in their own repo without writing them by hand.

Your setup

  • A Playwright suite (or Cypress or similar) in a GitHub repo, with your own fixtures, page objects and naming.
  • The new code is deployed to a test environment, for example staging.
  • You review every change as a pull request.

Say this to Certyn

For one feature:

Add a Playwright test for the new coupon field on checkout in github.com/acme/web. Follow our style and open a PR.

For each merge:

When something is merged to main in acme/web, write tests for what changed and open a PR.

To turn a saved Certyn test case into code, type /automate and pick the test case with @.

What Certyn does

  1. If there is no GH_TOKEN yet, opens a form for it. Make a fine-grained token for that one repo with Contents and Pull requests set to Read and write. It is saved as a secret project variable, never shown in the chat.
  2. Saves the repo as a project variable (GITHUB_REPO) so later runs know it.
  3. Clones the repo and reads the tests next to the feature: folders, fixtures, page objects, locator style, naming.
  4. Looks at the feature on the environment in a real browser to learn the real flow and texts.
  5. Writes the test on a certyn/... branch, reusing your helpers instead of adding new ones.
  6. Runs the new test several times against the environment.
  7. Opens a pull request that says what the test covers and how it was checked.

For each merge

Certyn asks which path you want:

Each merge, with GitHub Actions. The ci_setup form creates an API key. Save it as the CERTYN_API_KEY repo secret. Certyn then gives you a workflow on push to main (or opens it as a PR if the token has the workflow permission). It sends an instruction with the commit:

- uses: certyn-one/action@v1
  with:
    api_key: ${{ secrets.CERTYN_API_KEY }}
    project_slug: my-app
    environment_key: staging
    wait_for_completion: false
    instruction: |
      Commit ${{ github.sha }} was merged to main of acme/web.
      Start a run now: write tests for what this commit changed,
      in our style, run them on staging, and open one PR.

The instruction starts a Certyn chat that acts on it and starts the run.

Each night. Certyn creates an agent with the goal write tests for what was merged to main since yesterday and open one PR, and a nightly schedule in your time zone.

Each run reads the diff, writes tests next to the related ones, runs them, and opens a pull request.

What you get

  • One pull request with the new tests, in your folders and style: per feature, per merge, or per night.
  • A run report. If the new code itself is broken, a finding with evidence instead of a test that hides it.

Limits

  • The test runs against a Certyn environment. If the feature is not deployed there yet, Certyn cannot check the test. Deploy it first, or add the preview URL as an environment.
  • Certyn never merges and never pushes to your default branch. You review and merge.
  • GitHub App rules run Certyn suites only, not a goal like this. Use the Action or the nightly agent.
  • A chat started from CI cannot ask you to approve, so it cannot change settings. Do the setup (token, repo) in the chat on Home first.
  • A scheduled run has 60 minutes. A busy day can be too much for one run; then use the per-merge path.
  • Tests that need Java or Docker: use your runner, or let Certyn install a JDK at each cloud run.
  • Each run uses plan time.
PreviousTest your app on localhost while you developNextFix failing tests