WebElement Existence Checks

🙋 Questions
,
1

Hello,

I’m looking for a little general advice. At my enterprise we have a web app actually more than a few. Our Test Engineers currently want to write a bunch of what I refer to existence checks. The intent of the test is to ensure that the UI was displayed correctly with x, y, and z component.

My personal feeling is that this is trivial at most. I would prefer to write tests that would implcitly test element existence through testing functionality. For instance, i do not need an existence check on a Search button on a Search screen. Instead, why not author a test on searching? That would implicitly check for the Search button.

What are your thoughts? Any general practices that some of you advise to ensure screen validity in terms of appearance?

Thank you!

2 Likes
2

Hey,
I do not see the goal of either idea of automation.
Why do you or the team feel like automation would be a good idea to check those things?
Are there many refactorings with breaking design changes, are there many juniors in the team messing things up regularly, is the UI overcomplicated and easy to forget something, are there standards you want to adhere to, do the developers need feedback on the UI sooner than they get now from testers? have they found an interesting tool they want to use? are they bored and look for things to automate but have no idea what matters? or other reasons?

I’d find the reason/problem first and see potential solutions to deal with the problem.

1 Like
3

We have set up automated tests that check the visibility of elements (not existence because it will return true if hidden). It’s part of a test that is executed with different screen sizes to verify elements are in their proper state for supported screen sizes.

1 Like
4

Thank you for the feedback!

The reason for my approach is to test basic functionality. I’m thinking of it as a Smoke Test of the deployed code. In my approach, i prefer to focus on the functionality being tested and allow the existence of certain elements to be tested/validated implicitly.

I cannot speak for them at this time. But, i will take the feedback graciously and have a discussion in our next Guild to find out.

Thank you!

5

Morning :wave: ,

Without seeing/knowing the application it’s difficult to say “this is how I would test this” but here’s some food for thought for you to consider perhaps and discuss with your team.

Ideally, you should be pushing tests as far left as possible, this is because you get generally quicker feedback as the tests are quicker but also because the tests are usually less expensive to implement, maintain and run. Generally, UI tests should be very lightweight to test that your frontend for example hangs together. Quite often you will see things like testing of links, validation, text and that sort of thing within UI tests.

Unit tests
Instead, here for example if your application is MVC (Model-View-Controller), what you could do is introduce some unit tests to check the presence of specific UI components or elements. In those tests, if your View contains logic, or shows/hides certain elements you could unit tests those conditions.

Integration tests
Additionally, you might consider some integration tests if your application is MVC to check components work together as expected. Here you could test the Controller passing data for example to the View - ensuring the View renders for example the correct data, the existence of specific elements based on the state of the Model, or even dynamic content like a list of table is populated correctly.

UI tests
You could check the existence of elements here for example with Selenium but I’d strongly discourage this. Your tests not provide much value for the amount of effort involved, will be slow to execute and give feedback, and a pain to maintain.

Snapshot/visual testing
Something else to consider if the other options are not possible is snapshot or visual testing where you navigate to a page, take a snapshot and then compare that to a previous snapshot to see if things are rendered as expected. There are many free and paid for options out there to consider for example BackstopJS, Applitools, Percy. Again though, whilst you could implement snapshot testing and it’s relatively simple to setup, consider the value, effort etc, don’t just do it because you can.

I hope the above helps :slight_smile:

6

If it’s not something a user will perceive, don’t test it.

Selenium uses the concept of ‘visibility’ which as you note, unless the element is detectable by the human eye be being high enough in Z order and a decent enough width to not have it’s hitbox obscured by another hitbox nearby to it for buttons, all bets are really off for click ability, and probably for basic visibility too. Some kind of fuzz function that might inspect the element width and location and raise an alarm if an element looks like it could be near the edge of the viewport, that would be my start-point.

1 Like
7

Thank you for taking the time to provide feedback!

Ironically, the approach you have laid out is a part of our Master Test Strategy. This MTS is still new and the work put into it will drive us towards the suggested approach. The problem we have in the meantime is the current thought process. My hope is that as we align with the MTS that UI based unit tests become a part of everyday life. It is not as i write this. All new projects must adhere to the strategic application of test types. As you mentioned, we will be enforcing UI Unit testing is occuring. We are currently looking into Jest and Storybook as options. I am also driving towards elevating the use of mocking frameworks/tools for more lower level testing. The truth is we do not have the automation pyramid, we have the ice cream cone with a heavy reliance on Selenium based testing. We know this is not ideal and hence the realization for a MTS that takes test strategy into account.

The idea of screen validity should go away with the alignment with the MTS. Instead, my hope is that we drive thought processes towards functionality and features rather than visual representation. With no UI unit tests in place currently, our people think they need to do it post deployment.

I’m pleased that you provided this feedback and it actually aligns unknowlingly with the current direction we are headed!

Thank you!

2 Likes
8

To me, simply checking that an element exists doesn’t fulfil this requirement, as it may be in the wrong position, the wrong size, the wrong colour, etc. A good question to ask, which I know of through @testerfromleic and @mwinteringham, is whether you are testing the UI, or testing through the UI (TUTTU). It sounds like you want to test functionality through the UI, but the other testers are looking to test the UI itself.

If the goal really is to check that the UI is displayed correctly, I would go for some kind of visual testing tool, such as Applitools. With this, you can record a baseline screenshot of how the UI should look, and compare future screenshots to determine whether it’s still correctly displayed.

1 Like