Test Suites

Workflow Testing allows you to create sets of different tests to validate user flows are working as expected.

What is Workflow Testing?

Workflow Testing in Xano allows you to quickly build sets of tests that you can use to make sure a specific flow is working as expected. You can think of a ‘flow’ as a set of separate actions, such as multiple APIs that a user might hit when utilizing your application, or data processing across multiple function stacks. Workflow Testing allows you to validate these sets or flows with a single click and get instant visibility into your backend functionality.

How do I build workflow tests?

From the sidebar, switch to the Test & Deploy tab and choose Workflow Tests

Choose Add Workflow Test in the top-right corner. In the panel that opens, you can give your test a name, description, and add tags for easy access later.

Click the

button to add a step to your Workflow Test. We’ve introduced some new functions to assist you in building your tests. Run Stacks Run stacks are functions you can add to your workflow tests to run other function stacks, such as APIs, custom functions, and middleware.

Function Name	Use Case
Run API Endpoint	Sends a request to one of your API endpoints and returns the result
Run Addon	Runs an addon
Run Function	Runs a custom function and returns the result
Run Middleware	Runs a middleware and returns the result
Run Trigger	Runs a trigger and returns the result
Run Task	Runs a background task and returns the result

Test Expressions

Test Expressions are functions used typically in conjunction with a Run Stack to determine if the output of a Run Stack is valid.

Function Name	Use Case
Expect a variable to be defined Expect a variable to not be defined	Checks to see if a variable has been defined. Example: You have an API that returns a `user` object with a name key inside of it. You can use this to check if `user.name` is defined.
Expect variable to be empty	Checks to see if a variable exists, but is empty. Example: You are calling an external API that is used to process data. If the API call is successful, you know that `response.result` is empty because the API just returns a status code informing you that the job is being processed.
Expect variable to be false Expect variable to be true	Checks to see if a variable with a boolean data type is returning `false` or `true`
Expect variable to be greater than Expect variable to be less than Expect variable to equal Expect a variable to not equal Expect variable to be within	Checks to see if a variable matches the specific condition, such as >, <, =, or is within a certain range.
Expect variable to be null	Checks to see if a variable contains a `null` value
Expect variable to start with Expect variable to end with	Checks to see if the value inside of a variable starts or ends with a specific value
Expect function to throw	Checks a function to see if it throws an error
Expect function to match	Checks to see if the output of a variable matches a regular expression

Using Workflow Tests

In this example, we’ve built a workflow test to make sure our login flow works as expected.

We’ve added a Run Stack function to run our auth/login endpoint, and provided it with a username and password. After that, our Test Expression checks to make sure that the login function is returning an authToken, which is what our login endpoint returns if a valid username and password is provided. When we click Run we can see that our test passes!

If we modify our Run API Endpoint run stack to provide an invalid password, we can see that by running our test again, we get an error. This test has failed because an authToken was not returned.

Reading the results

From the main Workflow Tests page, run each test individually from its row, or click Run Test Suites to run all of them at once. Each test’s Result column shows an explicit Pass or Fail badge. When a test fails, its error appears full width directly beneath its row, so you don’t have to open the test to find out what went wrong. The Test Results panel summarizes the run:


Runtime	How long the run took.
Coverage	The share of objects that have tests authored against them.
Success Rate	The share of tests that passed.

The panel also shows when the last run happened.

Results persist per branch. A test’s last run status, duration, and error text are stored and shown when you load the page, so you can leave and come back without re-running the suite. Leaving mid-run and returning shows live progress, and an interrupted run reconciles on return.

If no workflow tests exist yet, the page shows a card offering both ways to create one.

Additional Information

Click the settings icon next to a workflow test to clone or delete it.
When adding a Run Stack, you can click theOpen icon to open that function stack being tested in a new window or tab and quickly make changes.
When you test a function stack that currently is in draft mode, your workflow test will run the drafted version.
You can change the data source that all of your workflow test’s functions run against by clicking the Live button at the top of the workflow test function stack.

Databases in Workflow Tests

Selecting a Data Source for a Workflow Test

When you select a data source for your Workflow Test, it’s important to note that a copy of the database is generated to ensure that no live data is impacted. This usually means that selecting your live database is not recommended — if your database is large in size, this can cause complications during testing. It is recommended to use separate Data Sources for running tests.

Build

Test & Deploy

Team Collaboration

Integrations

Security

Tutorials

Enterprise

Agencies

Account and Settings

Legal

What is Workflow Testing?