Using `checkMatch` and `testMatch`
The Project and CheckGroup constructs have two properties that allow you to use file-based routing to find and include Checks in your Project for testing and deploying.
checks.checkMatch
The checkMatch
property takes a glob pattern to match files inside your
project structure that contain instances of a Check, i.e. **/__checks__/*.check.ts
.
The goal of this property is so you as a developer can just add some files to an existing repo and not have to declare or import those files in some global config. This pattern should be very familiar to unit testing: the test runner takes care of finding, building and running all the files.
Also, removing a file has the desired effect: on deploy
the Check is removed from your Checkly account.
Here are some best practices:
- Store any Checkly related Checks inside a
__checks__
folder. This neatly indicates where your Checks are organized. - Use multiple
__checks__
folders throughout your code base, near the functionality it should be checking.
browserChecks.testMatch
The testMatch
property is very similar to checkMatch
and works mostly in the same way with some caveats.
The goal of this property is to allow you to just write standard *.spec.ts
Playwright files with no proprietary Checkly
config or code added — this is why it’s nested under browserChecks
as it only applies to Browser Checks. In turn, this
allows you to just use npx playwright test
on the command line to write and debug these Checks.
Some caveats:
- As a
.spec.ts
file does not contain any Checkly specific properties likefrequency
ortags
, the CLI will add these properties based on the defaults set inside thebrowserChecks
config object. Also, alogicalId
andname
will be generated based on the file name. - If you want to explicitly set the properties for a Browser Check and not use the defaults, you need to add
BrowserCheck
construct in a separate.check.ts
file and set file path to the.spec.ts
file in thecode.entrypoint
property. - When you rename a file that was previously deployed, the
logicalId
will change. The effect is that once you deploy again the newlogicalId
will trigger a deletion of the “old” Check and a creation of this “new” Check and you will lose any historical metrics.
multiStep.testMatch
The testMatch
property for Multistep checks work the same as for Browser checks described above.
Some caveats:
browserChecks.testMatch
will have priority to resolve directories. We recommend having a clear definition for each Browser and Multistep check to prevent loading the wrong check type. For example usingbrowserChecks.testMatch: ['__checks__/**/*.ts']
andbrowserChecks.testMatch: ['__checks__/multistep/**/*.ts']
will result in all checks created as Browser checks.
Note that the recommended patterns are just conventions. You can set any glob pattern or turn off any globbing by setting
checkMatch: false
and / ortestMatch: false
.
Last updated on September 16, 2024. You can contribute to this documentation by editing this page on Github