th-ui-tests v1.0.9

th-ui-tests

This project contains the Unit and E2E Automated tests for the Travelers Haven Portal (THP).

Setup

These steps cover how to setup this project to add and maintain tests. To add this project as a dependency in another project, see the DEPENDENCY_README.md.

Run npm install

This will install Cypress and Cypress plug-ins, along with other dependencies.

You will also need to add the .env file to the root directory. It contains sensitive data, such as passwords.

• The .env file is on Test Automation Space page in Confluence.

Configuration

This project currently uses the Cypress testing framework. Cypress can be configured by updating the cypress.json file. If you want to override these values for different testing environments, you can create another json file and pass it in the --config-file variable in the command line. This is useful if you want to point to a different host server or run a different set of tests.

Example: npx cypress run --config-file cypress.e2e.json This will run the E2E tests against the Staging environment rather than run the Unit tests against a local server.

Writing Tests

There are two main goals of this project: 1. Be able to share common code between projects. 2. Be able to easily port existing tests to a different testing framework in the future.

For the first goal, the developers and QA team realized it would be faster to write tests if we could share common code objects like page objects, fixtures, and helpers. In order to share, we decided to create a node package so the test code can be easily added as a dependency to other projects. Refer to DEPENDENCY_README.md to find out how to add this dependency.

For the second goal, we wanted to avoid using specific references to the current test framework in the specs, and instead write wrapper functions to abstract away the underlying syntax. This greatly reduces the amount of code that would need to be updated if we wanted to change tests over to a new framework.

For example, we may want to start writing mobile tests with Appium & WebdriverIO. If we already have tests written to test the Search feature in a desktup browser, it will take less time to re-use that same code if the test logic inside the spec is written agnostic of the test framework. Then, we would only need to update a few lines of code in page.actions.js to work with the new framework rather than updating a ton of code in the spec.

A concrete example is the scenario where we are converting Protractor tests over to Cypress. In Protractor, we wrote a test like this:

    it('should enter a Location', function () {
        searchBar.getLocationField().sendKeys('Denver');      
        expect(searchBar.getLocationField().getAttribute('value')).toBe('Denver');
   });

Since Cypress doesn't have functions called sendKeys and getAttribute, we have to re-write all of that code. But, if we had used wrappers, we would only have to update a small amount of code inside the wrapper functions:

    import searchBar from '../../../page-objects/thp.searchBar.page';
    it('should enter a Location', function () {
        searchBar.setTextboxValue(searchBar.location, searchVal);  
        searchBar.verifyTextboxValue(searchBar.location, searchVal); 
   });
   

   thp.searchBar.page
   
   // Inherited wrapper functions from page.actions.js
   
   setTextboxValue (control, value) {
       control.scrollIntoView().clear().type(value);
   }
   
   verifyTextboxValue (control, value, exactMatch = true) {
       this.waitForDisplayed(control);
       if (exactMatch) {
           control.should('have.value',value);
       } else {
           control.invoke('val').should('contain', value);
       }
    }
    
    waitForDisplayed (control) {
       control.should('be.visible');
    }
       
       

In addition to being more portable, the wrapper functions can do other valuable work like making sure the element is visible to an end user before trying to interact with it. This makes tests more stable. (Cypress does handle waiting for a control to be in a Ready state much better than most frameworks, but you can't count on every framework doing that.)

And now if we want to re-use this spec for a mobile test, we can again just update a few generic functions rather than a ton of spec code. Every page object inherits from a single base page.actions class, so there is only one file to update!

You can read more good info in this blog

Running Tests

NOTE: Before the tests can be run, the application under test must already be running. If you are testing against localhost, make sure the server is started first.

To run all unit tests: npx cypress run

To run all e2e tests against Staging: npx cypress run --config-file cypress.e2e.json

To run tests in the Cypress GUI: npx cypress open

To run against a PR app

You can either update the baseUrl and baseUrlApi variables in the appropriate Cypress config file -OR- pass in command line variables.

Command line example: npx cypress run --config baseUrl='https://th-web-tff-1352-remove--uxj2hw.herokuapp.com'

To run a subset of tests

There are two ways to limit a test run to a certain group of tests. One way is to update the integrationFolder config value and the other way is to use the cypress-select_tests plug-in that's installed in this project. The plug-in is based on Mocha, so it uses grep to filter by test titles and fgrep to filter based on filenames.

Note: When you use cypress-select-tests, Cypress will skip the tests that don't meet the filter and you will still see output for skipped tests.

Integration Folder Example: If you want to just run the Intern Lead Unit tests, set integrationFolder in the config file to "./cypress/integration/unit-tests/intern-leads" -OR- set it via command line:

npx cypress run --config integrationFolder='./cypress/integration/unit-tests/intern-leads'

Cypress-Select-Tests Example: If you only want to run the Adobe Intern Lead test, then type:

npx cypress run --env grep='Adobe'

-- OR --

npx cypress run --env fgrep='adobe'

Command line example using all the things

npx cypress run --config-file cypress.e2e.json --config baseUrl='https://th-web-tff-1352-remove--uxj2hw.herokuapp.com',integrationFolder='./cypress/integration/unit-tests/intern-leads' --env grep='Adobe'

This will use the E2E configuation, but only run tests with "Adobe" in their title under the intern-leads folder. It will run on a PR app instead of Staging.

For more info, refer to the Cypress documentation.