Here you can find some bits and pieces which could help you with writing your own tests using the Schrödinger testing framework. Additionally we will gradually expand this page with some additional useful examples, tips and tricks. If you are looking for some information on the initial set up for execution of the test please visit this page.
Important! PLease, pay attention that your midPoint instance is running with -Dmidpoint.schrodinger=true property
Each test class which is written extends the public abstract class TestBase, this contains some of the basic annotated methods, the ones which are of use at the moment are under the “@BeforeClass” and “@AfterClas” annotations.
The “@BeforeClass” annotated method checks if there is already a valid base configuration present, if not it initializes the Schrodinger “Midpoint” class with a set of base properties containing the reference of which type of Selenide web driver is being used (At the moment only the “Chrome drive” is tested and supported) and additionally the “schrodinger.properties” property file is loaded up and some additional test deployment specific data is fetched.
The “@AfterClas” should clean up the environment after a suite has executed. The method should execute the “Reset to factory default action” and thus rewert the environment to the initial state.
The “TestBase” also contains some common methods useful for many test implementations. These are the following:
importObject() : imports an object specified by the “path”
fetchMidpointHome(): returns a string representing the path to the “midpoint home” directory
refreshResourceSchema(): the “schema refresh” action for a specified resource is executed
initTestDirectory(): used in case there are additional files needed to be created for a test execution in a new directory dedicated for the test (i.e. creation of a resource .csv file)
Writing the actual tests
The instantiation of a class representing a GUI page is mostly done by calling the “basicPage” variable provided by the “TestBase” class which holds methods acting as accessors for most of the GUI pages. The method call returns an instance of the representative class for a specific page. The “page” classes each contain methods representing actions which can be executed on the components present on a specific page. Invoking a “page” method which returns an instance of a component will present you with the methods representing the capabilities of such component.
The tests are written in a “Fluent like” way this means that the original idea is to use “Method chaining” quite extensively. The main content of a test method should directly describe/represent each step which is done manually in the GUI.
To promote the readability of a large chain of invoked methods some rules of indentation are used. For now what proved to be the most useful method is to add a new line after each call of a method in the method chain and indent the calls in a way that each invocation of the same component on a page should be situated under each other. (e.g. see example above: "Example: Method chaining")
Sometimes we want to return back from a component of a page to the actual page from which the component was invoked or some parent component from which is was invoked. For this we use the “and()” method which returns the instance of the parent.
Example test suite
For the purpose of an example how an simple tests suite written with the use of Schrodinger could look like please look into the following link. The suite was created based on the PolyString test scenarios described in our list of basic test scenarios.