PSO-testing

Tables of contents

• About PSO-testing
• Technologies recommended
• Playwright
• Structure
• Writing tests
  • Keywords
  • Background
  • Steps tense
  • Scenario outline
• How to Run tests
• How to generate html report
• Conventions

About PSO-testing

The PSO-testing is a automated test framework designed to allow automate test cases about Commission European projects.

Technologies recommended

• Java 11
• Maven 3.9.6
• IntelliJ Community
• maven-atf-reports:1.0.0 (request to testing tower)

Playwright

Playwright (https://playwright.dev/) is a framework used to automate tests on web pages. It interacts with page elements (named locators) to check their behavior. Playwright uses core version of the browser (chromium, webkit and stable version of Firefox). It allows testing on stable browser versions which are not polluted by branding content and which are the most used. The version of those browsers will be the same for all people using the test project. In addition, it can also run tests on the local chrome and edge version.

Structure

Configuration file is split in data and locators (src/main/java/configuration):

• locators: all locators should be defined here. Each ui page should have its own java class.
• data: all test data should be defined here. Each ui page should have its own java class.

Helpers file for all helpers that supports our stepDefinitions (src/main/java).

Features file where should be defined all scenario tests. Use scenario outline if needs but avoid define test data here (src/main/java).

Framework file where should be defined all code to allow run the tests (src/test/java).

StepDefinitions folder where should be defined all cucumber steps (src/test/java).

TestRunner folder where should be defined the cucumber test runner (src/test/java).

Writing tests

Writing test cases in a correct way requires you to respect some easy rules. Our test cases are written with Gherkin syntax (https://cucumber.io/docs/gherkin/reference/).

All scenario and steps name should start with a lowercase letter.

Keywords

Gherkin as three main keywords for steps:

• Given for prerequisites steps
• When for actions steps
• Then for expectations steps

Keywords shouldn't be mixed: You should have this order of keywords: Given, When, Then. Note that a test couldn't have any Given steps if there is no prerequisites and in some rare cases it could happen that a test has no When steps.

E.g.:

Scenario: a user logs in
  Given a user opened the login form
  When the user fills the login form
  And the user validates the login form
  Then the user name should be displayed

Background

If all tests of your feature share some common steps, you can put them in a background. All background steps should be of Given type.

E.g.:

Background:
  Given the website is displayed
  And the user accepted the cookies

Scenario: a user logs in
  Given a user opened the login form
  When the user fills the login form
  And the user validates the login form
  Then the user name should be displayed
  But the login button shouldn't be displayed

Steps tense

Each type of step has its own tense rule.

• Given steps should be written in past tense most of the time as they represent prerequisites actions that have to be donne for the test's main action to be executed. But sometimes when the step is written in a passive way, given steps could be written in present tense
• When steps have to be written in present tense as they represent the main actions that will be performed in the test
• Then steps have to be written in conditional tense as the represent an expected behavior that could be not right when tested

If you have a step that is defined in a certain type and could be used as another type in another test, the step should be duplicated and written with the type format.

E.g.:

Scenario: a user logs in
  Given a user opened the login form
  When the user fills the login form
  And the user validates the login form
  Then the user should be logged in

Scenario: a user logs out
  Given a user is logged in
  When the user clicks the log out button
  Then the user shouldn't be logged in

Scenario outline

In some cases, a scenario can be used for several test cases with only some variations. In such a situation you can use a Scenario outline which will allow you to execute tests with parameters. To do that, you'll have to use create a Scenario Outline instead of a Scenario and define your parameters into your steps by putting them between <> (parameters should be written in pascal case). Then you'll have the define the parameters combinations in the Examples section.

E.g.:

Scenario Outline: a user <userStatus> logs in
  Given a user opened the login form
  When the user fills the login form
  And the user validates the login form
  Then the user <loginResult> be logged in

  Examples:
  | userStatus | loginResult |
  | valid      | should      |
  | invalid    | shouldn't   |

How to run tests

Run the following command

// to ui testing
mvn clean test -Dtest=ApiRunnerTest

// to api testing
mvn clean test -Dtest=UiRunnerTest

How to generate html report

To generate the report of the first time it´s mandatory install the dependency maven-atf-reports. It´s not available in the internet. Talk with testing tower to get it

Run the following command

 mvn com.qa.atf.reports:maven-atf-reports:1.0.0:generate@execution

After run the command with success, the html report will be available in target/pluma-report/overview-features.html

To add some information to report type the following code to the cucumber step:

 scenario.attach(<information to add>, "text/plain", <title>);

To add a screenshot to report type the following code to the cucumber step:

byte[] screenshot = page.screenshot(new Page.ScreenshotOptions());
scenario.attach(screenshot, "image/png", <title>);

Conventions

• cucumber tags: each feature file should be a tag with feature name and each test should be tag with test case number and initial letter of feature name (eg. L01 - first scenario to login.feature).
• write typing:
  • java class - pascal case
  • data and locators - snake case + upper case
  • feature files and methods name - camel case