When starting in test automation and we decide to learn how to write UI tests first, we need to keep in mind that we need to learn that the correct way and in the best way possible. We should not sacrifice the importance of UI tests flows by writing bad tests.
UI tests are relatively slow over time and slower than any kind of tests but that does not mean that we should not write them, we should write them the right way and follow the best patterns and practices.
I will be talking based on my experience and what I learnt through the years about the UI tests best practices which are listed below:
Small tests
They should be as small as possible which it is easy to read and to focus on what that test is achieving.
Independent tests
Test B should not depend on Test A result. This would cause problems when you start run your tests in parallel and it will make the tests so hard to maintain over time and lots of failures.
One functional assert per test
A test should have one functionality to test and ONE only, so the test should only assert one result, this test can have multiple of assertion statements but it assert one functionality in one screen of system under test.
Don’t write a complicated test
Tests should be simple to follow. I had an issue before which actually was my fault which made some tests big, complicated and had complicated mathematical operations which made these tests flaky.
Make it functional
I already talked on that on previous tips post.
Async/await
It is a great way to not letting the flaky tests appear is to async wait your UI elements to appear before doing any actions or assert on them. Think about if we are waiting some UI animation or a network call to finish before our UI elements appear on screen. We need to have smart waiting those elements. This means that also this async manner to wait some timeout for element to appear but not to wait longer or fail the tests. Lots of test automation platforms are having this way and we better use them.
Good asserts
We need to think clearly about which flows the tests are trying to assert giving correct and good asserts on the tests results. We just don’t want to assert anything on the screen or an UI on the screen, we need to focus on giving a great value by asserts for our tests.
Rich failure messages
Failing messages and handling test results in a good way is a great practice to follow because this helps everyone debug the test result or any failure that happens which results at the end in maintainable tests.
