Tests

Tests are pieces of code that use your app automatically and check that the result is right. With them, a change from the agent that breaks something old shows up right away, weeks before a customer complains about it.

Faundr shows which tests your project has, whether they pass, which ones are skipped or flaky, how much of the code they cover and, if you want to go further, whether they actually catch defects.

Supported languages

Faundr uses the test runners your project already has, without installing anything:

To run just one of them: !faundr tests-run --runner <name> (vitest, jest, playwright, node, pytest, flutter, dart, phpunit, pest, go, maven, gradle, dotnet, cargo, ctest, make or karma). The full table is in Supported languages.

Tests never run on their own

At the start of each session, Faundr only takes an inventory: which test runners the project uses, how many files and tests exist and any results already on disk. It doesn't run anything. Tests run when you or the agent ask:

!faundr tests-run

Useful options:

• --changed: only what changed since the last commit;
• --coverage: also measures coverage (see below);
• --files <files>: only some files.

A project with no tests

If the project has no tests yet, the Overview tab explains what they are and gives you the request to have the agent write the first ones: /faundr:tests. The agent:

1. asks what can't break (payments? sign-up?);
2. links each feature to the tests that protect it;
3. writes the missing tests one at a time, testing the way a user would, with the expected result written by hand and the error, empty and edge cases covered;
4. watches each new test fail once before trusting it (a test that never fails may not be testing anything).

Tabs

Overview

• The status card: "N tests failing" or "All tests passed in the last run", how many files and tests exist, the counters (Passed, Failing, Flaky, Skipped) and the last run of each test runner, with date and commit.
• Features and tests: one row per feature, tagged Protected, Partial or No tests. Features marked "can't break" that have no tests are highlighted.
• The Failing, Flaky (they pass and fail without the code changing), Tests that need attention (test problems found by Quality) and Slowest groups.

Tests

Every test, with Failing, Flaky, Skipped and All filters. Each row shows the last 10 runs as small squares: white passed, a light outline failed, dimmed was skipped.

The detail view shows What went wrong (the failure message) and the Fix with AI button (/faundr:tests-fix). The agent explains the failure in plain language, works out whether the bug is in the code or in the test and fixes the cause. It never deletes, skips or loosens a test just to make it pass. If it can't tell which behavior is correct, it asks you.

What changed

The question that matters every session: does what the agent changed have tests? This tab shows the percentage of new or changed lines that have tests and compares it with the rest of the project. The goal is simple: don't make it worse.

Below that, the session's files appear with the most untested lines first, followed by files that lost coverage without being touched. That usually means a test was deleted or broken.

Coverage

How much of the project has tests: the overall percentage and the list of files, with the most untested lines first. A file's detail view shows the untested lines and a request asking the agent to write the tests.

Measure coverage with !faundr tests-run --coverage. Each language uses its own coverage tool, which needs to be in the project: @vitest/coverage-v8 for Vitest, pytest-cov for pytest, Xdebug or PCOV for PHP, coverlet.collector for .NET, cargo-llvm-cov for Rust, gcovr for C/C++ and the JaCoCo plugin for Gradle. Jest, node --test, Flutter, Go and Maven measure coverage with nothing extra.

Mutation

Mutation testing answers whether your tests actually catch defects. Faundr breaks the code on purpose, a little at a time (swapping a > for >=, deleting a line), only in the parts the session changed, and checks whether any test notices. Every change that slips through becomes a T-n, described in plain language, such as "nobody tested a purchase of exactly $100".

• The card shows "Tests caught N of M planted defects", the overall score and the score where tests exist.
• A T-n's detail view shows the code, the change and the Write the test with AI button (/faundr:tests T-n).
• Ignore takes three reasons: the change is equivalent (it doesn't change what the app does, so no test can catch it), false positive, or later.

Mutation testing is optional and only runs when you ask: !faundr tests-mutation. It needs Stryker in the project and passing tests, and it has a time limit (5 minutes by default). It works with JavaScript and TypeScript tests (Vitest, Jest, node --test).

Findings from your own skills

If you already use a testing skill that isn't Faundr's (for coverage, TDD, test reviews…), you can connect it to the dashboard with /faundr:skills. Every time it runs, the agent records what it found at the end of the response:

• each missing test becomes a T-n in the Mutation tab, tagged via /name, and counts toward Launch and Insights like any other;
• when the skill runs again and the issue is gone, it closes on its own;
• each skill only closes its own findings, and only in the files it looked at.

See how to connect one in Workflows.

Errors and tests

A test that fails during one of the agent's runs also shows up in Errors. When the test passes again, the error closes on its own.

Commands