--- schema_version: "1" id: f0f48e8ed96721f1ddc790c766ac55fe2f31a013ce1ae39edc10c56415453f77 title: Example of a Test Suite collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/api-functional-monitoring/bat-example-test-suite.md canonical_url: https://docs.mulesoft.com/api-functional-monitoring/bat-example-test-suite source_site: docs.mulesoft.com content_type: documentation content_hash: 56c0643466c334e282e8faaa7690a5f19f325adfe4a5893ac3a9218d1333ed04 description: MuleSoft Documentation Site latest: true --- --- product: API Functional Monitoring --- # Example of a Test Suite > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To see the content of an example test suite, in a terminal create a directory in your computer’s filesystem. Then, change to that directory and run the `bat init` command. The command creates these folders and files: . ├── bat.yaml ├── config │   ├── default.dwl │   ├── devx.dwl │   ├── qax.dwl │   └── stgx.dwl └── tests └── HelloWorld.dwl The `bat.yaml` file is the main file for the test suite. This example contains these lines: suite: name: "Hello World Suite" files: - file: tests/HelloWorld.dwl reporters: - type: HTML outFile: /tmp/HTML.html # - type: SumoLogic # options: # SUMO\_ENDPOINT: # - type: PagerDuty # options: # PAGER\_DUTY\_ROUTING\_KEY: # - type: Slack # options: # SLACK\_WEBHOOK: # - type: Email # options: # EMAILS: # - type: NewRelic # options: # NEW\_RELIC\_LICENSE\_KEY: # - type: JSON # outFile: /tmp/JSON.json # - type: JUnit # outFile: /tmp/JUnit.xml Every test suite must contain a `bat.yaml` file at its root level. ## The `suite` Section of the example `bat.yaml` File The `suite` section names the suite. You can use any names that you like for the suites that you write. ## The `files` Section of the example `bat.yaml` File This example test suite contains only one test. The test is listed in the `files` section as the file `HelloWorld.dwl` in the `tests` folder. As you create tests, you add references to them in your `bat.yaml` file. For example, suppose that in your test-suite directory you create a folder named `api-tests` and write a test named `first-test.dwl` in that folder. In the `files` section of your `bat.yaml` file, you add the following indented line: file: api-tests/first-test.dwl If you write a second test, this one named `second-test.dwl`, you add this line next: file: api-tests/second-test.dwl The order in which you list the tests determines the order in which the BAT CLI runs them. In this example, the test `orderFulfillment.dwl` runs before the test `shoppingCart.dwl`: files: file: retail-site-tests/orderFulfillment.dwl file: retail-site-tests/shoppingCart.dwl To run the `orderFulfillment.dwl` test after the `shoppingCart.dwl` test, you can change the order in which they are listed: files: file: retail-site-tests/shoppingCart.dwl file: retail-site-tests/orderFulfillment.dwl Finally, you can create more than one folder to contain the tests in a test suite. You can even create subfolders within the folders that contain your tests. Just be sure that you provide the correct relative path when you list a test in the `files` section of your `bat.yaml` file. ## The `reporters` Section of the `bat.yaml` File This section is for configuring various tools or third-party applications to report test failures. In this example, a failure of the `HelloWorld.dwl` test prompts the BAT CLI to write a report of the failure to the file `/tmp/HTML.html`. For information about setting up reports, see [Configure and View Test Reports](https://docs.mulesoft.com/api-functional-monitoring/bat-reporting-task). ## The `secrets` Section of the `bat.yaml` File If you plan to run a test suite from a private location, you can use the BAT CLI’s integration with Anypoint Secrets Manager to use shared secrets in your tests. ## The `config` Folder You can store variables in the files in the `config` folder. For example, suppose that you’re developing an API and you deploy it to two different environments: `dev` and `qa`. The endpoint URL for the first is `dev.myapi.com` and for the second `qa.myapi.com`. The API is intended to behave the same in both environments. You want to test the API in both environments. However, instead of coding two tests, one for the deployment of the API in `dev` and one for the deployment of the API in `qa`, you can create a configuration file for each environment. In each configuration file, you can place a variable named `url` that holds that endpoint URL for the corresponding environment: The content of `dev.dwl`, the configuration file for the `dev` environment { url: "dev.myapi.com" } The content of `qa.dwl`, the configuration file for the `qa` environment { url: "qa.myapi.com" } In your test, you can use the `url` variable by placing it within this syntax: `$(config.variable)`, where _variable_ is the name of the variable that you want to use. Here is an example test that uses the `url` variable in a `GET` request to test the assertion that the response code must be 200: import \* from bat::BDD import \* from bat::Assertions --- suite("Hello world suite") in \[ it must 'answer 200' in \[ GET \`$(config.url)\` with {} assert \[ $.response.status mustEqual 200 \] \] \] When you run the test, you can use the `--config` parameter to specify which configuration file to use. (If you upload your test suite as a monitor to API Functional Monitoring in Anypoint Platform, you can specify the configuration to use when you create a schedule for the monitor.) Use JSON for the format of your configuration files, and `.dwl` as the file extension. You can put as many variables as you need in each file. ## The `tests` Folder In the example test suite, the test `HelloWorld.dwl` is in a folder named `tests`. As explained in the section about the `bat.yaml` file in this example, the `files` section in the `bat.yaml` file points to the tests in a test suite. ```yaml files: - file: tests/HelloWorld.dwl ``` In your own test suites, the folders that contain your tests can have any name that is valid for your filesystem. You can also place tests in multiple folders.