Core Layer Testing for OutSystems

Core Layer Testing is one of the biggest under-the-hood upgrades in JOSF 3.3.0. It gives teams a clean, predictable way to test their core logic without using the UI and touches the data layer directly. In this guide, we’ll walk through how the feature is used, why it matters, and what it unlocks for anyone who wants fast, deterministic test runs that catch real defects instead of noise.

Core Layer Testing, an introduction

For those who aren’t familiar with Core Layer Testing, this blog is for you. It gives an understanding of how test automation on OutSystems can be done and how it could change your understanding of testing OutSystems. Although the methodology is technology-agnostic, we specifically have implemented techniques for OutSystems with the release of JOSF 3.3.0.

In short, Core Layer Testing is about testing what matters; the business logic of software. Not how the software looks, but more the if’s and else’s of its code. Off-course JOSF is still very much able to automate and test your UI’s, but by using the Core Layer Testing methodology, you will unlock a more stable and scalable way of test automation. In JOSF, we’ve implemented this by steering OutSystems’ data actions, aggregates and many more directly via OutSystems native API’s.

Imagine a situation where you have a big project, in which you have hundreds of test needed to verify the quality of a system. Even though JOFS can handle the execution of multiple tests and browser executions with its parallel execution power [INSTER LINK TO PARALLEL SETUP], executing the same test via Core Layer Testing will always be faster, safer and more stable.

An example scenario for testing the business logic directly

In the video below, you can see that the two tests via Core Layer Testing have finished successfully, long before even the browser has logged in for the regular UI test.

---

Get started at testing what matters

To get started with Core Layer Testing, it is important to setup your project as an OutSystems project. This can either be a new project in JOSF, or changed from the preferences, by selecting the type of project from Web automation (default) to OutSystems automation.

By making this an OutSystems automation project, a lot of Core Layer Testing capabilities will be made available in JOSF. Since OutSystems is a web oriented application as well, all features of a default Web automation project will also be available, therefore an OutSystems automation project is an extension of a Web automation project.

Once created, navigate to the API Modeling section and create a new api model. This time, JOSF will ask if it’s an external API or an OutSystems application. Choose ‘OutSystems application’.

In the next wizard screen, you’ll be able to directly add credentials, and record a UI flow. There are already a couple of authentication types. If you are using OutSystems ODC with a default login procedure, choose ‘ODC – AWS Cognito Credentials’ and for OutSystems 11 with the React front-end, choose ‘OS11 – Default credentials’. For this example, we have an OutSystems 11 application, thus we use the ‘OS11 – Default credentials’.

Authentication setup

This type of authentication requires 4 parameters;

1. the username;
2. the password;
3. a Login viewname; and
4. a Login URL

The username and password are easy, there are your own credentials. Getting the correct Login view name and URL, are found by Recording the UI and login into your application. In the next example, we Record a UI flow and during that recording, we will login once. JOSF will keep track of all interactions between the OutSystems front-end and its server. From this interaction, we will extract the correct login view name and url.

Note that for this recording, we will not use the actual credentials, but that does not matter for this example, as we are only interested in the view name and the url.

We will record the Login flow, inspect the interaction between the browser and the server

---

If your authentication type is not in the list, please contact us and we will help you get setup!

Recording a test case

After you’ve setup the authentication, it’s time for our first recording. At first, you’ll notice that the CLT Action tree only consists of the base URL that was provided. This tree will be populated once we start and save our recordings. Alternatively, you can add requests manually.

For this example, we will record a test case to sign up for the waiting queue in the academy planner. Press the Record UI Flow button, to open up the recorder. This allows you to start a browser and start a recording. It’s possible to view the login credentials from the recorder, to easily refer back to this data.

Next up, you can execute your manual test case. Because JOSF is recording, you will see the list of CLT actions populated in the background. After you are done with your manual test case, stop the recording, select and inspect the requests you are interested in, which in our case is the ActionSignUpForWachtlijst.

Once recorded and saved, you can edit or execute the request with the Send button. This request will be sent as is, but when using input parameters, JOSF will prompt you for those to enter. These input parameters will also be prompted in a test script.

---

From recording to test case

Now that we’ve recorded our CLT actions and included them into our CLT Action tree, the recording is available as a recorded flow. You can open the recording to review, and directly create a test case, based on the actions previously recorded.

In our case, there is only one recorded action, but recording and selecting more actions, will create larger test cases.

Once pressed on Save, JOSF will create a new test case with the given name, and prompt you to directly open the test case. This will open the test and from here you can tweak and edit your test case.

Re-recording CLT actions

Once recorded, the CLT action is stored in the CLT Action tree, but as your team keep developing on your OutSystems app, your CLT actions require those updates as well.

Introducing the CLT action merger, in which JOSF helps you with updating previously recorded actions. If your CLT Action models have changed in OutSystems, but you are already using these actions in test cases, the easiest way to update these to the new model is to re-record the actions and JOSF will prompt you with the newly recorded action, and its current action. From there you can either add the newly recorded action to the CLT Action tree, or update the already existing one with the new data.

In the example below, after a recording, JOSF has detected the duplicate action “ActionSignUpForWachtlijst”. On the left-hand side you see the newly recorded action, and on the right-hand side the already existing action. JOSF will mark the changes, and in this case it used to require a “QueueId”, and with the new action, this property is not required anymore.

From here, we select the “Update existing CLT Action” and the right-hand side becomes editable, in which we can apply the changes either manually or by using the UI. In this case we overwrite the existing dat with the new CLT Action’s one and press Apply.

This example showed what happens if you remove properties from a Data Action, but off course this also works when properties are added or changed!

---

Go test what matters

You have now experienced what testing what matters looks like and how Core Layer Testing is possible in JOSF. Go and make your recordings, create tests from them and increase the quality of your product!

Happy Testing!