A good principle to follow in automated tests, particularly UI tests, is identifying a problem and failing the test as early as possible while also providing an error message which makes it easy to identify the root cause.
Let’s assume we have the following test case:
- Open www.google.com
- Search for “Test all the things”
- Click on the first search result
- …
Let’s imagine this test failing at step 3 (Click on the first search result) with an error message like: Cannot find element “searchResult”. Without debugging the test execution, can we quickly tell what the root cause is?
Not really. It could be a problem on the search results page, for example the search results not being rendered (or being empty). However, the problem could also be that the search results page never loaded in the first place and we are still on the homepage. In other words, our step 3 is looking for a UI element on the wrong screen.
In the second scenario, it would save us significant analysis time (especially in more complex tests) if the test already failed at the second step (Search for “Test all the things”) because that is where the actual problem lies.
Screen Identifier pattern to the rescue
A pattern we can use to improve this is what I call page objects with screen identifiers. Whenever a test is expected to transition the application under test to a new screen, we verify that the screen/page loads correctly before continuing with the test. Therefore, we define one (or multiple) UI elements that should be present on each screen. Ideally, these should be unique to the screen and load fast. If they are missing, we conclude that we are not on the expected screen and fail the test — right then and there.
#selenide #design-patterns #selenium #test-automation #java
