Nacházíte se zde: Úvodní stránka > Publikujeme > Blog > Automated integration testing of midPoint

Automated integration testing of midPoint

Automated integration testing of midPoint 123

This article is intended for readers with basic understanding of what is automated testing and what is identity management. For more information about identity management, in general, I suggest reading short series “Seriál o IdM” (first part)" on this blog written by my coworker Petr Gašparík.

Sdílej na sociálních sítích:

What is integration testing?

In this context by integration testing, we mean testing of whole IdM solution deployed on test environment with all connected systems. Integration testing, in general, is used as higher level testing which verifies the functionality of each part of solution working within the whole environment in concert with all other systems. For example, whether accounts are provisioned or attributes are generated properly.

About midPoint

The midPoint is most complex open source identity management available. It provides a wide variety of strong tools for efficient identity management. It also has a lot of extension points which enables substantial changes in look and behavior of IdM application. More comprehensive description of the midPoint is not in the scope of this article and can be found on the vendor’s website Technical description of midPoint can be found on vendor’s wiki

Why develop automated integration tests for midPoint?

The midPoint is a well-tested product as is so one could say why do testing again? But due to midPoints ease of customization and strong features allowing scripting you will probably find yourself creating a lot of logic by scripts and configurations within midPoint. This amount of logic needs to be regularly tested to ensure that new changes and product updates didn’t break it.

Unexpected dependencies might occur when a lot of attributes are generated or roles assigned automatically. Those operations are driven by clockwork mechanism which is tricky at best. You can not rely on any order of operations during automatic attribute generation and role assignment. When such dependency is accidentally introduced it might break at first sight independent functionality.

Luckily you don’t have to create selenium tests with extremely complicated and unreliable xpaths to look for dynamically generated elements in web GUI of midPoint. It is, of course, possible but midPoint has something much better. It’s SOAP and REST interfaces mirror all possible GUI operations. So you can use SoapUI and write simple XML requests and check well-structured XML responses. Testing of GUI is mostly done by Evolveum itself and you as IdM implementer can concentrate on testing of functionality you introduced.

About SoapUI

My favorite tool for integration testing of web service interfaces is SoapUI. Mostly because it has a free version but it is also the professional tool for developing executing and maintaining automated tests. Test development is done by user-friendly GUI.

SoapUI has good support for working with xml and properties files. Most of the work in SoapUI is writing of xml requests which are populated from properties so this support is essential. Properties files can be used to customize test templates and allow multiple tests to run simultaneously with their own data in one midPoint instance without the need to rewrite whole test suite.

Testing through SoapUI has also significant advantages even for development tests over manual testing. Test data can be set only once in the request and then executed several times until test passes. Repeated runs of tests are also much less labor intensive as are all kinds of automated testing.

SoapUI has also the major advantage because it is implemented in Java so it can run on all environments which have JRE. SoapUI is also possible to run from the console for server usage.

An essential way of use is running SoapUI tests from continuous integration platform. It has Maven task so it should be possible to run on most continuous integration platforms like Jenkins or Bamboo. It allows you to execute tests regularly independently and automatically and then check results. For example run tests each night and then look in your mailbox whether everything passed.

Practical examples

In the following section, I will describe two practical examples of SoapUI tests for midPoint. Those examples are intended to get you started in integration testing of midPoint by SoapUI.

But what does this test actually do? It is equivalent to the hello world program to demonstrate basic aspects of midPoint automated testing.

  • Initial test case creates new user in IdM.
  • Check employee and orgs case just runs query upon midPoint and asserts that at least one user is returned to check whether the user has been set up properly in the initial case.
  • Teardown case then deletes the user with which we worked previously.

Required software

I strongly suggest that you try following simple example be yourself. Nothing beats hands on experience in learning any topic. If you want to try the following example you will need some software installed and running. Luckily all required software is free.

In the first place, you will need running midPoint instance all installation instruction can be found here: If you deployed any application on Java application server before it should be easy for you. For the purposes of this example, you can get away with defaultly included H2 database. I suggest creating a dedicated virtual machine for this installation for example in VirtualBox.

Now when we have installed and running tested application we need to install the testing application. Such application is SoapUI which can be downloaded here:

Example test preparation

If you have both applications running you can now download example test suite templateTest.xml and properties of the suite With both files downloaded, you can import templateTest.xml.

SoapUI will ask immediately for properties file which you also have downloaded.

Next thing you have to do before running this suite is configuring your ws-security configuration. Configuration window is accessible by double click on project folder in SoapUI. WS security has to be done in the way highlighted in the picture below. Username is the name attribute of any user in midPoint with proper privileges (administrator has all of the privileges). More about ws authorization in midPoint can be found here: . Part of the authentication process is also time. So make sure that on the machine with midPoint and machine with SoapUI has the correct time set.

Last part of preparation is changing of URI of test requests. Requests are all elements with gray soap box logo. Their URI need to be changed to point SoapUI to your midPoint instance.

You also have to make sure that previously defined ws-security is set in each request so they are not outright refused by midPoint.

Now you can run the whole suite and it should end up wholly green like in the following picture.

Example test description

In the following section, I will describe the structure and all steps executed within this simple test suite.


I have decided to split test suite into three test cases. This structure can then be reused because the only middle case is usually changed and data preparation and cleanup stays pretty much the same for all tests. The uniqueness of test data across different tests is ensured by setting properties.

Setup should consists steps preparing data.

Teardown should contain steps deleting data and resetting environment to the previous state like nothing happened.

Middle case is used for concrete test and should be focused on testing only one feature.

You might wonder why I didn't include more actual tests in the test case. It would introduce major troubles when extending and merging tests in version control. So I try to have on test project file for each functionality to minimize the need for merging.

Test steps


Properties step reads properties from property file of standard format. (key=value)

Property transfer

Property transfer serves as it seems from its name to transfer properties from one step to another. It can extract properties not only from property step but also for example from the response of request step.


Request step executes SOAP request on defined URL. It receives the response and is also able to check various assertions on response to check whether tested functionality did what it should.


Running tests

You can execute tests from GUI in a  way. Just double-click any part of test suite tree including testSuite itself and click run.
Feature to disable individual test steps might come in handy during test development.


Complex example

In the following section, I will describe more complex test which is actually used in our environment.

Tested functionality description

We have complex functionality regarding user account lifecycle in our midPoint deployment. One point (not the first and by far not the last) in such lifecycle is user disabling upon the date of his contract's termination. This situation is the one which this test tries to verify.

How does the midPoint know users contract ends? We have custom attribute effective end date in the user object. This attribute is set when contract termination date is known.

What is the desired midPoints behavior? On the effective end date but no sooner than that midPoint should disable user account and all other accounts provisioned from this account in all end systems.

How is it solved in midPoint? We run regular task which searches for users which are enabled but their effective end date is already in past. If this task finds some users like this he executes all operations required upon contract termination.

  • Setup phase creates tested user and his direct line manager. The line manager is here just for the sake of completeness of the data because he is referenced from our user.
    • The midPoint also automatically creates and assigns new roles and organization for users country, department, division and team.
  • Recompute-Check employee simulates the situation of contract termination from HR system
    • First, all properties are set to make sure that test works with his own user created during setup.
    • Then we find oid of the newly created user. This is the identifier in midPoint which we use later for operations with the user.
    • After that, we prepare time which is exactly one minute after now.
    • In update EED request we set that time as users time of contract termination (effective end date)
    • We wait one minute to make sure that time to disable user has passed.
    • To be sure that no error happened during update we check that user is still enabled.
    • We start task which is responsible for periodic user disabling upon their contract termination.
    • Wait one second. Waiting is here to decrease a number of checks whether the task is still running.
    • Check the state of the task.
    • Conditional repeat step is used to conditionally jump to another step. In this case, we use it to jump to step wait 1 sec until the task checking state of task doesn't end in success (midPoints task has finished)
    • As the last step, we retrieve the user from midPoint and check whether he is disabled properly.
  • Teardown case then deletes user his manager and all the automatically generated roles and organizations.
Interesting test steps

Because I discussed basic test steps in the previous example I will concentrate on more interesting steps in this example.

groovy script

You can use groovy scripts in SoapUI. In this example, I used it to get current time + 1 minute.

REST requests

Because I didn’t find a way to start midPoint task by SOAP I have used REST request. Working with REST request is a bit different than working with SOAP request. REST request needs to have declared resource first before it can be added to test case.


conditional repeat

Last interesting step of this example is the conditional repeat. It allows you to create cycles within test execution. In this example, I use it to wait for midPoint task to complete.


Other unmentioned possibilities

There are several other possibilities how to use SoapUI for midPoint testing and development. Most obvious one is testing of the interface of new end system for which you are developing connector. It is very handy to understand this new interface from hands on experience before you start coding.

Functional tests can also be easily transformed to load tests. You just configure manner in which load is created (concurrent tests running, requests per second etc.)



Creating automated tests is, of course, more time consuming than just creating functionality. So when you want to start with automated testing you have to include test creation in your estimates and evaluate test scope which will be automated (only happy day, all error messages, corner cases, behavior with some data missing or corrupted, etc.).

Automated testing should have the major impact on final solutions quality over a long time. When the solution is done and will be no longer expanded there is no big incentive to run automated tests regularly. But when there is any new development it is major time saver having automated tests to check whether any existing functionality was affected by the new one. The biggest impact of good test coverage is better confidence of developers in making major changes and improvements without fear of breaking everything else. If such a thing happens automated tests will report it soon in the development cycle and the following fix is much cheaper in time and money than when discovered later on after some priceless production data were corrupted.

Automated testing also allows the much more rapid pace of change without costly complete regression tests.

Thanks to good web service interface of midPoint automated test development are much easier than in the case of other applications with only web GUI.


Author: Oskar Butovič

Přejít na začátek stránky

Mapa stránek

© Copyright 1998-2014 AMI Praha a.s., powered by AMIGO CMS