Coverage overview

mabl's coverage feature allows you to browse your app's test coverage to more easily identify gaps and quickly find which test run on each page. On this page, you'll find a list of all the pages that mabl has explored in your app via the default link crawler in the last two weeks. You can specify if you only want to view data as new as one day or as old as the last four weeks.

Understanding coverage

For each page in coverage table, you'll be able to view the most recent screenshot from the link crawler as well as the specific URL host and URL path in the first three columns, respectively. You're also able to filter by the specific host and path, in addition to selecting the age range of data you'd like to view. You'll need to run your link crawler regularly to take advantage of this feature. If the link crawler is not run regularly, the calculations may not accurately reflect the coverage of your application.

Frequency of coverage page updates

All measures are updated at least once a day

Test Coverage

The above metrics only present the executed test coverage from the past two weeks (by default). Unique steps or tests that are recorded on a specific page but are never executed, due to an upstream test failure or conditional logic, are not included in these totals.

In addition to the above, mabl provides multiple measures to understand your level of existing coverage for a page:

Tests

The metric captures the number of unique tests that have visited that particular page in the timeframe defined above, regardless of whether or not they interact with elements on the page. If the number is 0, this means that no tests visit this page other than the link crawler. Click anywhere in the row to view the specific test that run on this page, or easily add your own if none exist.

Note: if a test is part of two plans and runs against that page twice, only the first unique run will be reflected here.

Steps

This metric captures the number of distinct interaction steps from tests that visit this and are executed on the page in the selected time frame. Steps are distinguished by the element they interact with and what action they perform.

Note: because assertions, wait steps, echo steps, etc. do not interact with the elements on the page, they are not included in this total.

Assertions

This metric captures the number of distinct assertion steps from tests that visit this and are executed on this page in the selected time frame.

Complexity

This metric measures the overall complexity of the DOM itself as measured by mabl when crawling the page or during a regular test run. The higher the number, the more interactive elements the page contains such as buttons, links, and fields.

Linked Pages

The metric captures the number of pages that link directly to this path as detected by the mabl link crawler. The deeper a specific page is within your app, the lower this value will likely be. If you have not run your link crawler recently, this section may appear empty.

Depth

This metric captures the number of clicks necessary to access the specific path (starting at 0) as recorded by the link crawler. For example, your app homepage will have a depth of 0 while your login page will likely have a depth of 1. If you have not run your link crawler recently, this section may appear empty.

Daily Users

This metric captures the averaged daily number of unique users that visit the specific page using data captured from Segment data in your own application.

Segment Integration

Please visit this link to set up the integration. Feel free to contact us in-app or by email with any questions you may have.

By integrating with Segment, mabl uses your real user data, via the Page and Track methods, to securely build a model of the pages in your app and determine the number of unique users interacting with each page. mabl does not process personally identifiable information (PII) as part of our Segment integration.

Common Use Cases

How can I find which high traffic pages are lacking test coverage?

By default, the results on the coverage page will be sorted by complexity in descending order. Once you've integrated with Segment, click the "Daily Users" twice to sort your coverage by the average number of daily users in descending order. Once the data has loaded, view the "Tests," "Steps," and "Assertions" column to easily identify pages lacking comprehensive coverage, as shown in the box below.

Where to find the "Daily Users" column, as well as two pages that are lacking test coverage.

Where to find the "Daily Users" column, as well as two pages that are lacking test coverage.

How can I determine which pages have the most existing test coverage in a specific environment?

By default, mabl won't aggregate coverage data across environments (e.g app.myapp.com & dev.myapp.com). Type the URL host of the specific environment you'd like to view and wait for the table to populate with your data. Then, click on "Tests," "Steps," or "Assertions" to view the tests which have the most of each respective coverage type. This is also a great way to identify which pages may be visited by many tests but are lacking in steps that interact with or assertions that verify the page itself.

Where to find the "URL host" field. As we can see, this environment doesn't have much coverage at all.

Where to find the "URL host" field. As we can see, this environment doesn't have much coverage at all.

How can I find my existing test coverage on pages that are linked to heavily in my app?

To do so, you'll need to sort your coverage by "Linked To" in descending order. You'll view all of your pages ordered by the number of times the page was linked to by other parts of your app discovered by the link crawler. This helps you identify which pages are most frequently linked to and where they may lack coverage, as well as the number of users that are visiting the page on average.

The location of the "Linked To" tab within the coverage page.

The location of the "Linked To" tab within the coverage page.

Updated 8 months ago

Coverage overview


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.