1

What are useful and practical asserts to consider in our web automation project which uses selenium (java) to automate an eCommerce web application. As this is my first website to automate, I am running out of ideas where i can verify things expect few which i know mentioned below:

  1. Verify each page Title
  2. Verify a button, text, link, image, custom text etc

Apart from these is there any thing else i can verify?

3 Answers 3

2

It depends on your testing objectives, the number of verifications you can do to a website is infinite.

We have no background knowledge about your project so it is hard for us to understand what "common assertions" are.

Having said that, my personal opinions are:

  • Verify each page title, header (normally h1).
  • Verify if key elements are present, such as buttons, texts and etc.
  • Does a page load within the specified time box?
  • When you click on a button, does a prompt dialogue box pop out?
  • Are all buttons responsive to clicking?
  • Is there any hidden element on this page that will only appear under a certain condition?
  • Are there any overlapping elements?
  • Does your mobile version of webpage have the same "look and feel" with your desktop version?

Above is plenty of work for you to start with, but please do talk with your project stakeholders.

0

The asserts I commonly use are:

Assert that:

  • An element is present based on a CSS identifier, ideally ID
  • An element is present based on other selectors and attributes that make it unique
  • When a user choose an option that should present a form, a form element is then present
  • A form element is correctly not present (e.g. not redisplayed due to error) after submit
  • The correct markup is present after an action is performed
  • An error form has the correct markup and information for validations
  • When I submit a form, application pages then list the new item as added
  • When I delete content as a user, the deleted content no longer shows on relevant pages

You'll notice that all but the first two are 'take this action and then verify that the page content is as expected'. Even the first two can be after an event. I think this is where you are struggling the most based on your description which basically described the elements present on initial page load. Testing adds much more value when you have a state, an action and then a resulting state that you test against.
You'll also notice that I don't list asserting text here. You can do it but it is one of the worst approaches as users change text and so do languages. Consider it an assertion of last resort and hopefully avoid it altogether.

Avoid or be conservative in the following assertions because they are brittle, likely to break and require maintenance over time:

  • specific text for large blocks of text or text that is likely to have wording changed
  • specific text in one language when the site serves multiple languages
  • identifiers such as css class which may not be or remain unique
  • identifiers that are overly specific and include page layout

I also use a Page Object approach for my element selectors so my tests look like this:

context 'the driver correctly', :happy do

  scenario 'adds a violation', :js do

    visit_ready auto_policies_path(current_step: s4_path)
    
    add_valid_violation(child_seat_violation)
        
    wait_for_ajax
    
    expect(page).not_to have_css p.css_new_violation_form
    
    expect(find(p.css_added_violation)).to have_content child_seat_violation
    # ^^^ assertions

  end
end
0

Look at the requirement document and the test plan document. On that it should clearly mention what should test and what should not to test. So based on the above 2 documents you will be able to identify what kind of elements you need to assert.

Not the answer you're looking for? Browse other questions tagged or ask your own question.