GUI Testing With Schrödinger

Last modified 15 Nov 2021 16:18 +01:00
This page may be outdated.


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

Schrodinger framework module path



Schrodinger tests module path



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 properties file present in {schrodinger_tests_module_path}/src/test/resources/configuration/ and add the following values:

Property name Description Possible value


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



The password to log in the system



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



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



The name of the web driver



the path to the web driver executable which you downloaded before



Url of the remote web driver.


The flag to use or not to use remote web driver



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



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


  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


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

mvn clean install -P all-tests


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 -P configless


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

mvn clean install -P 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!


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 * *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 base_url=http://localhost:8080/midpoint

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



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.


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


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='']}


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


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.


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


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 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


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.


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


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.


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.