TestVibe generates Playwright tests from behavior you describe in plain language — most flows never need a plugin, since you describe the click, the assertion, and the navigation, and the AI writes it. Plugins are for the parts that reach outside the browser tab: an email inbox, an LLM judgment, a Jira ticket, a database row. Here's what ships in the built-in catalog, how to enable one per project, and when reaching for one beats the workaround you'd otherwise write.
What a plugin actually adds
A plugin adds steps you can call from Gherkin. Install one, and its capability becomes available to every feature in the project — you describe the intent in a scenario, and generation wires it into the test. Nothing about your normal authoring changes; you're just handing the generator a tool it didn't have before.
Take email verification. Without a plugin, a signup-with-confirmation flow is awkward to test: you can't read the message the app just sent, so you end up mocking the mail service, disabling verification in a test config, or hard-coding a code that drifts out of sync with reality. With the MailSlurp plugin installed, the flow reads like the real thing:
Scenario: New user confirms their email before first login
Given a fresh test inbox
When I register a new account with that inbox address
Then a verification email arrives within 30 seconds
And opening the confirmation link activates the accountThe scenario describes behavior; the plugin supplies the capability to read a real one-time inbox. That's the whole model — behavior in the feature file, capability from the plugin.
The catalog
TestVibe ships with roughly 14 built-in plugins, and all of them are visible and installable from the catalog — nothing is hidden. The Plugins section in the navigation rail is a searchable marketplace with category filters (AI & LLMs, Integrations, Reporting, Data & Utilities, and Frameworks) and an Installed shortcut.
Here's the built-in set, grouped by what you'd reach for it to do:
| Plugin | Category | What it gives your tests |
|---|---|---|
| OpenAI | AI & LLMs | Call GPT models to summarize, classify, and make natural-language assertions. |
| Anthropic Claude | AI & LLMs | LLM-powered checks — assert intent, grade output quality, explain failures in plain English. |
| TestVibe Assistant | AI & LLMs | AI vision comparison: judge a live screenshot against an Asset Library baseline. |
| Visual Regression | Reporting | Pixel-diff screenshots against a saved baseline and flag unexpected visual change. |
| Sentry | Reporting | Link runtime errors captured during a run to the failing test for faster triage. |
| GitHub | Integrations | Open issues, comment on pull requests, attach run artifacts. |
| Jira | Integrations | Create and transition issues when tests fail, with run links and screenshots. |
| Slack | Integrations | Notify a channel with run results, pass rates, and links to failing tests. |
| Mattermost | Integrations | The same run-result notifications, for a Mattermost channel. |
| MailSlurp | Integrations | Read one-time codes, magic links, and SMS codes from disposable test inboxes and numbers. |
| Faker | Data & Utilities | Generate realistic randomized test data — names, emails, addresses. |
| REST Client | Data & Utilities | Call HTTP APIs and assert responses as steps, alongside the UI. |
| Wisej.NET | Frameworks | Drive Wisej.NET controls (combo boxes, trees, data grids, date pickers, ribbon buttons) reliably. |
| PostgreSQL | Data & Utilities | Listed as a database helper — check the plugin's detail page for what's currently wired up before relying on it. |
You can also publish your own packaged steps from the upload action in the rail, to share an internal helper with your team.
Enabling a plugin per project
Installs are scoped to a project, not to your account, and they persist. Turn one on and it stays on across reloads, and every teammate on that project sees it installed until someone removes it.
- Select Plugins from the navigation rail.
- Search or pick a category to find the plugin.
- Select Install on its card. Installed plugins show an Installed badge; select the badge to update or remove.
If a card ever looks out of sync right after you toggle it, use the catalog's Retry option to refresh from the server rather than assuming the install didn't save — the toggle persists server-side even when the card hasn't caught up.
Configuring what a plugin needs
Plugins that talk to a third party need credentials — a Slack webhook, a Jira token, a Faker call needs nothing. Where a plugin does need values, its detail modal shows a Requires section: each requirement carries a Set or Not set badge, and the header counts how many are still missing.
You can fill a value inline in that field, or set it on the dedicated Settings → Variables & Secrets panel. Either way it lands in the project's variables and secrets, where secret values are write-only — saved once, never displayed back. Reference them from steps the same way you reference any stored value:
When I open a Jira issue in project "{{var:JIRA_PROJECT_KEY}}" using token "{{secret:JIRA_API_TOKEN}}"The token resolves at run time inside the sandbox, so the secret never appears in the feature file, the generation context, or the run logs. If a plugin step fails with a missing-value error, the entry name in Variables & Secrets not matching the token exactly is the usual cause.
When a plugin beats a workaround
The honest test for reaching toward a plugin: would the alternative make the test lie about what your users experience?
- Email and SMS verification. Mocking the mail provider or disabling verification in a test build proves your app works with verification turned off — which is not the thing you shipped. MailSlurp reads the real message, so the test exercises the real gate.
- Fuzzy output. An exact-string assertion on AI-generated copy, a localized date, or a summarized paragraph fails on noise that a human would call correct. An OpenAI or Claude check asserts intent — "the summary mentions the refund policy" — and survives wording that doesn't matter.
- Unique test data. Hard-coded emails and usernames collide on unique constraints the second time a suite runs. Faker produces fresh, realistic values every run, so setup stops fighting itself.
- Visual drift. Eyeballing screenshots doesn't scale and doesn't gate a pipeline. Visual Regression pixel-diffs against a baseline in your Asset Library and only writes expected/actual/diff images when something actually changed.
- Failure routing. A failing run buried in a dashboard gets seen when someone looks. Slack, Jira, and GitHub plugins push the result — with links and screenshots — to where the team already works.
When the workaround is cheap and honest, skip the plugin. When it forces the test to stub out the very behavior you care about, install the plugin and describe the real flow.
Install only what a project uses — every installed plugin's keywords surface in authoring suggestions, so a lean set keeps generation focused. For the full catalog and per-plugin setup, see the Plugins docs. Ready to generate tests that reach past the browser tab? Get early access.