> For the complete documentation index, see [llms.txt](https://docs.buzzy.buzz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buzzy.buzz/the-building-blocks/release-tests.md).

# Tests

Tests are repeatable checks for important app workflows. They help you confirm that an app still works after changes to the brief, flows, data model, blueprint, screens, theme, functions, widgets, permissions, APIs, MCP, or settings.

Tests are also a design tool. Writing a test forces you to name the user journey, starting state, actions, expected result, and proof that the app behaved correctly. That makes flows and logic easier to reason about before users depend on them.

## What Tests Cover

A saved test records the workflow target, viewport, steps, expected proof points, and run history. Tests can cover practical smoke and regression paths such as:

* sign in, registration, onboarding, and logout
* main navigation
* list, detail, create, edit, submit, approve, delete, and search flows
* booking, payment, request, review, support, or notification workflows
* role-specific admin and audience behavior
* row access, field access, and Private Data behavior
* functions, widgets, and code-widget interactions
* mobile, tablet, and desktop viewport variants

The test workflow can use app metadata such as the brief, flows, blueprint, data model, runtime screens, stable test IDs, and deterministic action paths to plan or replay checks against the live runtime.

## When to Use Tests

* Before publishing or sharing an app with real users.
* After changing the data model, screens, permissions, functions, code widgets, widgets, constants, MCP, APIs, or integrations.
* Before promoting an app between development, staging, and production environments.
* When a workflow has broken once and should become part of the regression suite.
* When a flow is complex enough that writing a test will clarify the logic.

## How to Think About a Good Test

| Test question           | Example                                                                                                         |
| ----------------------- | --------------------------------------------------------------------------------------------------------------- |
| Who is the user?        | A customer, admin, reviewer, field technician, or anonymous visitor.                                            |
| Where do they start?    | Login screen, dashboard, record detail, public form, or deep link.                                              |
| What should they do?    | Search, create, edit, submit, approve, assign, upload, reveal, or delete.                                       |
| What should change?     | A row is created, status changes, task appears, notification sends, function result displays.                   |
| What should not happen? | Denied users cannot see rows, edit fields, reveal Private Data, or open admin screens.                          |
| What proves success?    | Visible confirmation, row count growth, changed field value, expected screen, or absence of restricted content. |

## Recommended Coverage

Start small. Cover the workflows that would cause the most damage if they broke:

* one happy path for the primary user journey
* one create/edit path for the main datatable
* one permission-sensitive path
* one failure or empty-state path
* one mobile path for the most important screen
* any function, widget, API, or MCP-backed path that users rely on

Tests do not replace human review. Use them alongside visual review, permission checks, [Security Review](/the-building-blocks/security-review.md), preview testing, and real user acceptance testing.

## Debugging Failed Tests

When a test fails, use the [In-App Debugging](/troubleshooting/in-app-debugging.md) to inspect the affected screen.

Common causes include:

* a view or form is not bound to a datatable
* a field points to a missing or wrong field
* a screen action points to a missing destination
* row context is not being passed
* a filter context is not connected to the intended view
* a function or widget expects a different input shape
* permissions or Private Data rules hide data that the test expected to see

## Related Pages

* [Testing Approaches](/the-ultimate-guide-for-vibe-coding-an-application-with-ai/project-workflow/testing-approaches.md)
* [Security Review](/the-building-blocks/security-review.md)
* [In-App Debugging](/troubleshooting/in-app-debugging.md)
* [Release Management](/advanced-deployment-settings/installation/release-management.md)