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
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, preview testing, and real user acceptance testing.
Debugging Failed Tests
When a test fails, use the In-App Debugging 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
Last updated