3

Should we write scripts that work 'page by page' or 'by functionality' which may mean several pages?

  • if it’s page by page how do we verify the success criteria for any element?
  • if it’s by functionality how to verify other generic validations?

Note we are using Java but obviously this question is not language specific

2

I agree with the other commenters that the Page Object Model is a great way to structure test code for interacting with the page, however, for the tests themselves, I recommend writing tests for functionality instead of page-by-page.

Tests aren't about validating pages, after all. All of your users and most of your staff don't care which page something is on, they care whether it works or not.

There's a bit of nuance. Unit tests will often run against a single component of a page, whereas functional tests run across multiple pages. For a functional test, grouping by functionality reflects how your developers will make changes, and allows for sensible multi-page tests. For instance, imagine you're writing a mortgage application. There are five steps for making a new application:

  1. Create an account or log in on the homepage
  2. Provide your ID
  3. Provide the property details
  4. Provide your financial details
  5. Submit the application

Your users will never visit the 'Property Details' page directly. They must take the other steps first.

If you wrote 5 separate page tests, you'd have to make extra, crappy tests for each page to make sure it was receiving and providing the right data. If you add a new page between 4&5, you now need to change the test code for page 4, the new page, and page 5.

If your application is composed of re-usable components, page-based tests make even less sense. Say users can provide financial information without logging in, on order to estimate how much they can borrow. If you're using page-based tests, you have to write and update both tests when that component changes.

If instead you're doing functionality grouped tests, you can instead create a page object for that component and write a unit tests for it. Then, during your functional tests, just pass the page object the relevant data for either page, and assume that

2

I recommend writing the scripts for functionality.

However I recommend staying to the full path (end to end) for the functionality being tested. However, this does not cover many of the cases or tests that are usually desired, therefore, in addition to selenium tests for full functionality I also try to have:

  • 100% unit test coverage
  • unit test coverage for a variety of 'sad' cases such as blank param, invalid param, null param, param missing, etc. I often call this "500% coverage"
  • js tests. Many apps today are using js for single page functionality. The modern frameworks used such as React, Angular and Vue provide good capability for good tests. They can be orders of magnitude faster than selenium tests. Think 1-2 minutes compared to 1-2 hours for selenium based tests.

Essentially, save your expensive (in terms of time and resources), slow and brittle selenium tests for:

  • Going through the entire process successfully in a real browser
  • Testing different browser devices happy paths

Follow the agile testing pyramid which has

  • Many (thousands) of unit tests that have their dependencies mocked and stubbed
  • Hundreds of integrated tests that ensure parts work together
  • A few dozen UI selenium tests that make sure the functionality works in a real browser.
  • A few manual UI tests to ensure that an actual human can see the actual screen elements and be able to work with them in a real physical device.

Tests per page can be good cases for UI unit tests in frameworks such as jest and jasmine. However they will typically not be device dependent to test device specific issues.

1

Try using Page Object model, to verify the elements let the function return boolean value and check if it's not false. For example, if you got click on login button create a function with try catch. If the element is available then click on it and return true else return false.

1

Option1: If you want to use selenium for page by page verifications, you can use page object model in following way:

/***
 * Tests login feature
 */
public class Login {

  public void testLogin() {
    // fill login data on sign-in page
    driver.findElement(By.name("user_name")).sendKeys("testUser");
    driver.findElement(By.name("password")).sendKeys("my supersecret password");
    driver.findElement(By.name("sign-in")).click();

    // verify h1 tag is "Hello userName" after login
    driver.findElement(By.tagName("h1")).isDisplayed();
    assertThat(driver.findElement(By.tagName("h1")).getText(), is("Hello userName"));
  }
}

Option 2: If you are using selenium framework to test web UI, accessibility and API services, then preferable to use cucumber boilerplate:

Reference: webdriverio/cucumber-boilerplate Sample Cucumber Feature File with maximum reusability:

Feature:
    In order to keep my product stable
    As a developer or product manager
    I want to make sure that everything works as expected

Scenario: Check title of website after search
    Given I open the url "http://google.com"
    When I set "WebdriverIO" to the inputfield "#lst-ib"
    And I press "Enter"
    Then I expect that the title is "WebdriverIO - Google Search"

Option3: If you want to use an automation framework for locally built app for web UI, preferable to use Cypress instead Selenium:

Feature: Home Page Test on OrangeHRM website

   Scenario: Check valid home page tabs display
      Given I open OrangeHRM homepage
      When I SignIn as user
      Then the user name should be displayed
      And the Admin tab should be displayed
   
   Scenario: Click on Admin Tab of home page
      Given I open OrangeHRM homepage
      When I SignIn as user
      And I click on admin tab of home page
      Then the admin sub tab section displayed

Reference: narayananpalani/cypress-test-techniques.

0

I would recommend using page object model where you create a specific class where you put all the elements/objects and actions can be done within a page that makes them reusable to test cases that you'll automate.

0

You must note that selenium is an automation tool and not a test library. Having said that its always preferred to write tests (usually provided by manual testing services) with respect to functionality.

Given we have the tests (or scenarios incase of BDD) then automation scripts for these tests can be programmed using your preferred combination of test library (JUnit, TestNG) and automation tool (Selenium). For purposes of code maintainability of you can use design patterns like Page Object Model or Screenplay Pattern.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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