> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](https://regexr.com/) |
### 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.
From the main **Workflow Tests** page, we can run each of our tests by clicking the individual buttons, or we can click **Run Test Suites** to run all of our workflow tests at once.
We can see by running all of our workflow tests the following information:
* We have **38% coverage**. This means that out of all of the function stacks that exist across our backend, 3/8 of them are used in our tests.
* We have **50% success**. This means that out of all of our workflow tests, half of them are successful.
* To run all of our tests takes less than a second.
#### Additional Information
* Click the **settings** icon next to a workflow test to clone or delete it.
* When adding a Run Stack, you can click the**Open** 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
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](/the-database/database-basics/data-sources) for running tests.