Assertions are critical for building effective automated tests that yield meaningful results. If the goal of writing tests is to ensure that specific functionality works in a way that matches defined expectations, the assertions are the steps that define those expectations.
By following best practices, you can ensure the assertions you create in the mabl Trainer yield the most value for what you are testing.
Keep the end goal in mind
Context matters. If you're trying to create a simple smoke test to validate that nothing is catastrophically broken, your assertion should focus on ensuring that the most critical elements of your application are appearing. In a test like this, adding assertions to every label on the page doesn't match the goal of the test, since you don't care so much about minor details as you care about the primary functionality.
On the other hand, if you are creating a regression test whose goal is to ensure that one specific feature is working exactly as you would expect, adding assertions on the labels present can help validate that your user will have the expected experience using that feature.
Find the strictest condition that doesn't overspecify
The more specific we get with our assertions, the more likely they are to fail tests erroneously because of a change that might not be important to us. However, if our assertions are too broad, the test may indicate everything is fine when in fact a regression failure has occurred.
For example, if you want to assert that the URL is showing the correct page for a logged in user at a certain point in the test, you could create a URL assertion against the pathname. By setting the assertion type, you can control how strict the assertion is:
- Assert that pathname equals "{{@user_id}}/settings/apis"
- Assert that pathname ends with "settings/apis"
- Assert that pathname contains "settings/apis"
If the goal is to make sure the application is showing the API settings page, but the specific user ID isn't so important, the ends with assertion type is a good choice: it is sufficiently strict without being overspecific.
Use variables to create dynamic assertions
By using variables, you can create assertions that are based in the context of the test execution to help verify consistency. Consider the use of variables in the following workflow:
In an ecommerce application that creates and processes orders:
- Record the steps to create a new order.
- Extract the order ID number from the page and store it as a variable.
- Navigate to a page that shows the summary of recent orders.
- Assert that the text of the first order matches the order ID variable.
If you want to use a variable value that was extracted from a page element, but the value includes extra characters, you can use a JavaScript snippet to remove the characters you don't want. See the snippet examples page for an example in use.
Learn more
Whatever strategy you take for assertions in your application, make sure that you are on the same page as other members of your team. For more information on specific types of assertions, refer to the guides listed below: