Story Tests

As the story tests contain almost complete sophisticated scenarios they are not only interesting to developers but also to system engineers. The configuration used in story tests can be used as an inspiration for midPoint configuration in similar real-world scenarios. Therefore pages like this one document the story tests. Each page describes the basic idea of the test and the most important part of the configuration that is used in the test.Documented story tests:

Story tests are integration tests. Therefore please see the Integration Tests page for a general introduction to midPoint integration tests. This is important information to understand the development of story tests.All the story tests have some very basic common configuration (in src/test/resources/common). This common configuration mostly consists only from the objects that are essential for every midPoint instance such as system configuration, administrator user and superuser role, scanner tasks and so on. There is also couple of testing users that can be reused in the tests. But that’s all. All other configuration much be loaded by each story test.There is an AbstractStoryTest superclass that the story tests extend. This is just a convenience class that loads the common configuration. Otherwise it is almost empty.The basic steps to develop a new story tests are:

Story tests are not executed during normal build of the entire midPoint system (mvn clean install). Therefore you can create pretty intensive configuration without impacting midPoint build time. Individual tests are easy to execute from command-line even without using the special profile:

The story tests are executed in bamboo longtest plan which is executed usually once per day. Therefore if you modify a story test then keep an eye on that plan. You will be expected to fix the test if it fails.