At mabl, we believe that quality is best managed as a team. To get the most out of your mabl tests and improve overall collaboration, we recommend prioritizing “test readability.” The following best practices ensure that your tests are easier to understand:
- Use low-code steps when possible
- Keep assertions focused on the end goal
- Avoid validating too many outcomes in one test
- Explain the intent of test steps
- Use test naming conventions
Use low-code steps when possible
In mabl, you have the flexibility of creating test steps through our low-code interface or through custom methods. Examples of low-code steps include recorded clicks and taps in the Trainer, native assertions, and low-code response validations in the API Test Editor. Examples of custom steps include custom finds and JavaScript snippets.
While custom steps are great for implementing last-mile use cases, we recommend using low-code steps whenever you can for the following reasons:
- Coverage: Low-code steps are quicker to create than custom steps, which in turn makes it easier to build test coverage.
- Collaboration: Low-code test steps are easier for all members of the team to collaborate on. In contrast, creating a test with a lot of custom steps often limits the number of people who can contribute to test maintenance.
Keep assertions focused on the end goal
Assertions identify what the test is validating. Before you begin creating a test, think about the end goal, using these questions as a guide:
- What are you trying to validate?
- What actions do you need to take to validate this outcome?
- How can you assert that each action works as expected?
When assertions align with the end goal of the test, it’s easier to understand what the test is checking and isolate issues when the test fails.
For more advice on creating effective assertions, check out the following articles:
Avoid validating too many outcomes in one test
While there isn’t a one-size-fits-all approach to testing, tests are easier to understand if they’re scoped to a specific outcome.
Readability isn’t the only reason to create shorter, more focused tests. When tests contain hundreds of steps, the following obstacles emerge:
- Longer feedback cycles: With longer test run times comes longer feedback cycles. If your tests are running in parallel in your development pipeline, the plan can’t continue until all the tests in the stage have completed. By creating smaller, more focused tests with a shorter run time, you can execute parallel plan runs more quickly and reduce release cycle times for your app.
- Maintenance burdens: If a test fails on step 248, you may have to spend more time getting your application in the correct state for troubleshooting.
To reduce complexity and make your tests easier to read, limit the scope of your tests to a clear outcome. If you can accomplish the testing end goal over multiple user sessions, consider breaking up a single test into multiple smaller tests.
Explain the intent of test steps
Add further clarification and descriptions to test steps to make them easier for your team to understand.
In browser and mobile tests
In the mabl Trainer, there are several options for explaining the intent behind test steps:
- Echo steps - add echo steps to describe different sections of the test. If you put “#”, “##”, or “###” at the start of an echo step, it becomes a header that visually breaks up different parts of the test.
- Rename steps - double-click on test steps and update the step name to a more meaningful description of what the step does.
- Annotate - for steps that need even more clarification, add an annotation to give even more context.
In API tests
By default, API steps show the METHOD and request URL. Add request names in the API Test Editor to make steps more human readable.
In the following example, the first step uses a request name that explains what the request does. The subsequent requests in the test show the default METHOD and request URL for comparison.
Use test naming conventions
Test naming conventions make it easier for your team to understand the purpose of a test at a glance and avoid creating redundant tests.
When establishing test naming conventions, think about what’s important to your team. A sample naming template might include:
- The application under test
- The test case ID
- The area of the app that you’re testing
- The specific outcome
For example, at mabl we use the following template for naming tests: app - module - specific test case name. Examples of tests that follow this template include:
- “App - Tests - Sorting and filtering on the tests page works as expected”
- “Marketing - Registration - Register for a trial”