cdp-portal-tests

Cdp Portal test suite

• Requirements
  • Node.js
• Local development
  • Setup
• Test suite requirements
  • Running portal using cdp-local-environment
  • Running portal using cdp-portal-stubs
  • Running the test suite
  • Debugging
    • WebdriverIO Plugin
    • Setup in IntelliJ/Webstorm
    • Debug environment variable
    • WebdriverIO debug command
• Best practices
  • Finding elements in tests
  • Components
  • Page objects
  • Spec files
• Licence
  • About the licence

Requirements

Node.js

Please install Node.js >= v20 and npm >= v9. You will find it easier to use the Node Version Manager nvm

To use the correct version of Node.js for this application, via nvm:

cd cdp-portal-tests
nvm use

Local development

Setup

Install application dependencies:

npm install

Test suite requirements

• mongodb
• redis
• localstack
• cdp-portal-stubs
• cdp portal running and pointed at stubs/local services

Running portal using cdp-local-environment

Note there is currently a bug on macs where this does not work

The easiest way of setting this up:

• clone cdp-local-environment
• start the portal profile

$ docker compose --profile portal up

Running portal using cdp-portal-stubs

You can also set up your local suite of Portal apps via cdp-portal-stubs

• clone cdp-portal-stubs
• start all the applications listed in the README.md

Running the test suite

To run the suite headless:

$ npm test

To run the test suite with a browser:

This makes it much easier to debug

npm run test:local

To run a specific test with a browser:

npm run test:local -- --spec ./test/specs/TESTFILE.js

Debugging

WebdriverIO Plugin

In IntelliJ and Webstorm use the WebdriverIO Plugin. This provides full run, debug and breakpoint capabilities in your WebDriverIO tests.

Setup in IntelliJ/Webstorm

1. Add a WebdriverIO configuration template
2. Run -> Edit configurations
3. Edit configuration templates -> WebdriverIO
4. Add the following values to the WebdriverIO configuration template:
5. Add an All tests configuration
6. Run -> Edit configurations
7. Add new configuration -> WebdriverIO
8. Add the values shown in the following image:
9. You can now run and debug your tests in IntelliJ/Webstorm:

Debug environment variable

You can also set the following env:

This provides debug config in the wdio.local.conf.js file

DEBUG=true

Or use the npm script:

This script automatically sets the debug environment variable

npm run test-local:debug

WebdriverIO debug command

Use the following command in code:

browser.debug()

Best practices

• Keep these tests organised, clean and maintainable as this repository is likely to grow in size with the cdp-portal-frontend
• Test the cdp-portal-frontend as a user would use it
• Test the important flows, not too many, just enough to give you confidence. User Journey tests are expensive
• Have a read through WebDriverIO best practices for more information

Finding elements in tests

When writing tests, pages and components change. To avoid complex, brittle selectors. Or selectors coupled to CSS classes or JavaScript hooks, you should use [data-testid="<name>"] attributes. Using test data attributes allows you to find elements via an explicit testing hook, which rarely changes. This is a more robust way to find elements in tests and avoids having to unnecessarily update tests.

For example:

1. Finding an element traversing the DOM using CSS styling classes

   Find the second button in the grid on the right of the page inside a div with the classes container and grid

2. Finding an element using CSS styling classes

   Find the button with the class app-button and app-button--secondary

3. Finding an element by data attribute and text content

   Find the button with the data testid attribute [data-testid="create-microservice-submit"] and the text Save

As you can see the last option is much more robust. It avoids using CSS classes that change. It avoids referencing and traversing the DOM, which can be brittle. It avoids having to update tests when nothing has really changed tests wise.

Components

The component helpers are based on components or groups of elements in the cdp-portal-frontend. These helpers provide simple methods to test flows and components.

Page objects

The page objects are based on the pages/domain objects found in the cdp-portal-frontend. All page objects extend from the Page class which provides common methods for all pages.

Spec files

The specs are the flows/features found in the cdp-portal-frontend that we are testing. This is where the tests and expectations can be found.

Licence

THIS INFORMATION IS LICENSED UNDER THE CONDITIONS OF THE OPEN GOVERNMENT LICENCE found at:

http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3

The following attribution statement MUST be cited in your products and applications when using this information.

Contains public sector information licensed under the Open Government licence v3

About the licence

The Open Government Licence (OGL) was developed by the Controller of Her Majesty's Stationery Office (HMSO) to enable information providers in the public sector to license the use and re-use of their information under a common open licence.

It is designed to encourage use and re-use of information freely and flexibly, with only a few conditions.