mesmer submit does pretty much everything it can with a given application binary.
- Upload your binary to a new build in the current project
- Pick an appropriate device to replay tests
- Queue up test replay
- Queue up an application crawl
- Block until the all queued jobs start to take place.
This is what that looks like when you call it:
$ mesmer submit my-app.apk ─── Creating the build ✓ Uploaded build Build ID aaaaaaaaaaaaaaaaaaaaaaaa ─── Queueing up jobs ✓ Got test configuration ✓ Found compatible device(s) ✓ Selected device for tests ✓ Tests in queue ✓ Crawl in queue ─── Waiting for jobs ✓ Tests in progress ✓ Crawl in progress Crawl ID bbbbbbbbbbbbbbbbbbbbbbbb ─── Done! Tests https://some-tenant.mesmerhq.com/home/xxxxxxxxxxxxxxxxxxxxxxxx/testresults/aaaaaaaaaaaaaaaaaaaaaaaa Crawl https://some-tenant.mesmerhq.com/home/xxxxxxxxxxxxxxxxxxxxxxxx/app-map/aaaaaaaaaaaaaaaaaaaaaaaa
Optionally, you can pass
--no-test to skip crawling or skip testing, respectively.
For more control over test execution, you can use
--tags Tag1 Tag2 etc to only run tests matching one of several tags. See
mesmer test start for more information.
To enable a11y auditing, pass the
--a11y flag. This will audit with the first a11y policy configured in your Mesmer tenant. To use a particular a11y policy, you can pass the policy ID (from
mesmer a11y policies) with the
This command is all you really need to integrate Mesmer with your CI environment. You can use environment variables to pass in your tenant url, project id, and authentication token (generated on a developer machine).
# This configuration can live wherever your CI platform likes to keep its secrets $ export MESMER_TENANT="[your tenant url]" $ export MESMER_AUTH_TOKEN="[your auth token]" $ export MESMER_PROJECT="[your project id]" # Then, in your CI script: $ ./my-build-script-or-whatever --output build.apk $ mesmer submit build.apk ...etc...
mesmer will pick up its configuration from the environment here, and happily upload and test your fresh build.