GUI Testing With Schrödinger

Last modified 28 Apr 2023 13:49 +02:00
This page may be outdated.

Introduction

This page describes the set-up and usage of the "Schrödinger" testing framework for GUI tests. This feature is available for several midPoint versions, however, it is still experimental.

Important: starting from midPoint v4.3 Schrodinger testing framework and Schrodinger tests were separated to a separate project. Therefore all the information which concerns these changes will be marked with "v4.3 and later" note.

before v4.3 v4.3 and later

github repository

https://github.com/Evolveum/midpoint

https://github.com/Evolveum/schrodinger

Schrodinger framework module path

midpoint/tools/schrodinger

schrodinger/schrodinger-framework

Schrodinger tests module path

midpoint/testing/schrodingertest

schrodinger/schrodinger-tests
Writing tests

If you are looking into writing some tests via the Schrodinger framework or you are executing the tests via some other means than the mvn command (e.g. trough your favorite IDE) please also check out this page.

Initial Set-Up

To be able to execute the tests written via the Schrodinger framework, there are a couple of initial steps to be taken:

  1. Pick a browser on which you wish to execute the tests and download the corresponding webdriver supported for executing selenium tests** the latest ones for the Chrome web browser can be found here

    • Important: chromedriver version must match version of your Chrome

  2. Locate the schrodinger.properties properties file present in {schrodinger_tests_module_path}/src/test/resources/configuration/ and add the following values:

Property name Description Possible value

username

The name (login) of the user to log in the system

administrator

password

The password to log in the system

5ecr3t

base_url

The url which is used when midPoint is started within Schrodinger tests running

http://localhost:8180/midpoint

base_url_mp_already_started

The url of already running midPoing. Used only when startMidpoint=false (v4.3 and later)

http://localhost:8080/midpoint

webdriver

The name of the web driver

CHROME

webdriverLocation

the path to the web driver executable which you downloaded before

/opt/chromedriver

remoteWebdriverUrl

Url of the remote web driver.

useRemoteWebdriver

The flag to use or not to use remote web driver

true/false

headlessStart

The flag to start or not to start a browser while tests running

true/false

startMidpoint

The flag to start or not to start midPoint for tests running

true/false

locale

The identifier of the locale to be used over midPoint during tests running. Important: locale is also used for property keys translation with the help of midPoint localization files. Therefore, the value of the locale property should match one of the available locales from midpoint-localization project.

default: en, other possibilities: fr (France), it (Italy) etc.

  1. A JDK 8 (1.8) or higher is needed to be referenced on your path for this feature to work.

    • in general, JDK at least of version used for building midPoint

    • in most cases, JDK 8 should be ok, but since midPoint 4.0, JDK 11 is strongly recommended

  2. Before v4.3 execution using maven:
    With the project already built, execute the following maven command from /midpoint repository

    mvn integration-test -DskipSchrodingerTests=false -pl testing/schrodingertest

v4.3 and later All tests are divided into several groups. It depends if the test environment should be prepared (e.g. applying new schema or post initial objects importing) before starting the tests or not. A table with existing test profiles is given below. Resources folder should contain the files in the corresponding folders to prepare a test environment: extending_schema.xsd file should be situated in resources_folder/schema folder; midPoint object files (*.xml) to be imported before midPoing start should be situated in resources_folder/post-initial-objects folder; csv resource sources files should be situated in resources_folder/sources folder.

Group/profile name Description maven command Resources folder path

all-tests

The profile runs all the tests defined in testng-integration.xml

mvn clean install -P all-tests

configless

The profile runs a group of tests which don’t require test environment preparation in advance. This means that all the objects which are used in the test are created/imported within the test.

mvn clean install

fundamental-labs

The profile runs the tests which cover fundamental midPoint training labs.

mvn clean install -P fundamental-labs

schrodinger/schrodinger-tests/src/test/resources/fundamental-labs

  1. You are capable to customize the execution a bit more, this is stated at a further section of this page and essentially that’s it. Have fun testing!

Startup

The boot up of the application is indicated with a message similar to this one :

Midpoint (a version of the build you are testing) booting up for integration testing, embedded Tomcat instance configured to listen on port: (port number, either default or configured)

Default Parameters And Optional Test Execution Arguments

While executing the tests there are also a couple of additional arguments which can be supplied to change the default test environment parameters.

  1. Server port for the embedded Apache Tomcat server. The default value is 8180. Can be changed using the argument -Dserver.port. Please also bear in mind that the server port has to be changed in the *base_url *property in the *schrodinger.properties *property file as well.

  2. The midpoint home directory. How the default is set is described on the following page. Can be changed using the argument* -Dmidpoint.home*

  3. By default, there is a home directory created during the boot up of Midpoint or there can be one assigned via the midpoint.home argument. If you wish to remove such directories after the test execution finishes, there is a cleanup option present as well. By default it is set to false *but this can be changed using the *-Dcleanup argument.

  4. The whole bootup, test, clean up part of the integration tests cycle can be ignored if needed using the switch -DskipTests

The following will execute the integration test suites using the /home/midpoint/schrodinger directory as midpoint home and executing the embedded tomcat using the port 8181. After the suite finishes the process will be stopped and the created or supplied directory will be removed.

mvn integration-test -DskipSchrodingerTests=false -pl testing/schrodingertest -Dmidpoint.home=/home/midpoint/schrodinger -Dserver.port=8181

Test Run With External Tomcat

If you want to run Schrodinger Tests against your external midPoint instance, follow this setup (let’s assume default run):

  • specify correct URL in schrodinger.properties: base_url=http://localhost:8080/midpoint

  • change port in testing/schrodingertest/pom.xml: server.port8080/server.port

Troubleshooting

Symptom

Test run ends on message Midpoint 4.0.1-SNAPSHOT booting up for integration testing, embedded Tomcat instance configured to listen on port: 8180: with no further progress.

Solution

Embedded Tomcat didn’t start. Run midPoint on your own Tomcat and set enviroment as in Test run with external Tomcat.

Symptom

Tests timeouts with something like:

Timeout: 6 s. +
Caused by: NoSuchElementException: no such element: Unable to locate element: {method:xpath,selector://\*[@data-s-resource-key='PageAdmin.menu.top.configuration']}

Solution

Run Tomcat with this parameter:

set JAVA_OPTS=-Dmidpoint.schrodinger=true

Schrodinger coverage of GUI code

On the current moment Schrodinger coverages all the pages that can be reached with the help of the left side menu. Also Schrodinger coverages the pages that can be reached only after the appropriate configuration is set (e.g. Forget password page, or configured object collection pages). The structure of the Schrodinger code repeats mostly the structure of the GUI code. All the pages and components can be divided into several groups according to the functionality. The table with Schrodinger code coverage details is provided further.

Group name Description Covered functionality GUI components Schrodinger class

Object list pages

Pages with the list of objects of the specified type presented in the table

Main component of such pages is table, therefore most functionality is covered within table component.

Pages: All users, All roles, All services, All resources, all pages from the Cases, Certification, Server tasks sections, all pages from the Certification section, all pages Created reports, All reports, Audit Log Viewer, All archetypes, All object collections, All objects

AssignmentHolderObjectListPage

Object details pages

Pages which display object details, usually presented with tabbed panel.

Summary panel, tabbed panel with ability to select different tabs, operational buttons panel (e.g. Change archetype functionality, Run task, etc.), options panel (e.g. Force, Reconcile, etc.), save, preview changes.

Details (new or edit) page for user, organization, role, service, resource, case, campaign definition, task, report, archetype, object collection; system configuration and internal configurations pages.

AssignmentHolderDetailsPage

Object list table

Table to display a list of objects

Search panel functionality, selecting menu item by item name or by menu item button class, redirecting to details page, work with table rows and columns, buttons toolbar functionality (e.g. add new object button, export button)

All object list pages' tables, Assignments tab table, Inducements tab panel and others.

AssignmentHolderObjectListTable, TableWithPageRedirect, Table

Tabbed panels

A set of tabs with its panels, usually used on the object details pages.

Select appropriate tab

e.g. tabs on the user details page or system configuration page

TabPanel

Tab panel

Frequently used tab panels with container value form or with table. Tab panels with its own GUI elements are covered as separate components.

Different tab panel UI is covered for Delegations, Delegated to me, all tabs under System and Internal configurations menu sections. Container value tab panels: Basic, report tabs, system configuration tabs, resource configuration tabs. Tab panel with table: Assignments, Projections,Object policy, Inducement.

e.g. tabs on the user details page or system configuration page

TabWithTableAndPrismView, TabWithContainerWrapper

Form

Form is a panel with generated object attributes. One form can contain one or more container panels.

Ability to work with form and its attributes, set up, update or remove value.

e.g. form panel on the Basic tab of the Edit user page

PrismForm

Popup windows

Every popup that appears in GUI

Each popup panel is covered according to its functionality.

The most commonly used are confirmation window, object browser popup, new assignment and new projection popups, export configuration popup and report configuration popup.

ModalBox

Test coverage

All Schrodinger tests are divided into several groups: gui pages tests, gui components tests, scenarios tests and labs tests.

Integration with an automation server (Jenkins)

An automated work is set on Jenkins to run daily Schrodinger tests.

Further framework extension

TODO

Adding custom test suites

The execution of test suites is orchestrated via the maven failsafe plugin. To add additional test cases to the suite execution you will need to modify the suite configuration file.

Defaults

By default, the information of which test classes are the subject of execution is present in the testng-integration-schrodinger.xml suite configuration file at the root of the schrodingertest module.

If you would like to change the name or path to the suite configuration file, this change has to be done in the project POM file of the schrodingertest module. The configuration is present in the plugin with the artifact maven-failsafe-plugin.

<suiteXmlFiles>
    <suiteXmlFile>testng-integration-schrodinger.xml</suiteXmlFile>
</suiteXmlFiles>
Was this page helpful?
YES NO
Thanks for your feedback