In this chapter, you’ll apply what you learned about test suites in the previous chapters. To do so, you will build a simple test using the various test suite items.
In this chapter
To follow along with this tutorial, download the sample solution file from the link below.
Theme: Build a test
Time: 15 minutes
Unzip to any folder on your computer.
Start Ranorex Studio and open the solution file
Before we start building our test, we need to define what it’ll do. We’re keeping it simple, so our test will only add an entry to a database and then validate whether it’s been added. Our AUT will be the Ranorex Demo Application. The required steps are:
Our sample solution already contains the required recording modules. Let’s take a look at them.
The modules are organized in two folders. The application functions folder contains the modules needed to control the application itself, i.e. starting and exiting the Ranorex Demo Application. The database functions folder contains the modules related to adding an entry to the database.
The modules in these folders are quite specific, as you can see from their names. They each contain only the actions necessary for an individual step in our test definition. Modules built in this way are easier to reuse. This gives you more flexibility when building tests.
We’ve got everything we need, so let’s get to business and start building our test. There is one test suite in our project,
RxDatabase.rxtst. It should already be open. If it isn’t, simply double-click the file in the project view.
In the test suite view, you’ll see that the test suite is mostly empty, except for a single test case with the default name. Our test definition lists starting the AUT as the first step, so that’s what we’ll add first. Starting the AUT is a perfect example of a module to include in a global setup region because, without it, no other test steps will work. To add a global setup region:
In the test suite view, right-click the test suite and click Add setup.
From the module browser, drag the module StartAUT to the setup region. In addition to starting the demo application, the StartAUT module also clicks on the Test database tab, which is step 2 from our test definition.
Steps 3 to 9 in our test definition represent adding an entry to the database and validating it. This is the core of our test, so it should get its own test case. We can use the existing test case, but let’s first give it a more meaningful name.
To rename it:
Click the test case and press
Rename it to SimpleDatabaseTest and press
Now we can fill the test case with the required modules. These are, in test definition order: InsertName, SelectDepartment, InsertAge, SelectGender, AddEntry, and ValidateEntries. You can add the first four modules in any order you like, but AddEntry must be second-to-last, and ValidateEntries must be last.
To add the modules:
From the module browser, drag the modules to the test case.
Ctrl + Click.
The modules InsertName, InsertAge, SelectGender, and SelectDepartment are all part of the same process: defining the data that will be added to the database, in other words, inserting a person. This is why it makes sense to organize them in a module group. This way, you won’t have to add all four modules over and over again when you create more test cases where this process is needed. To add the modules to a module group:
In the test suite view, select the four modules using
Ctrl + Click or
Shift + Click.
Right-click the modules; and then click Group selected modules.
The newly created module group opens in the module group view.
Rename the module group to InsertPerson and close it.
The test case now contains the module group InsertPerson and the module group also appears in the module browser for reuse.
As tests grow larger and more complex, it can become difficult to manage the test suite. Smart folders are a useful structuring item to overcome this issue. Instead of filling a test case with 50 modules that all logically belong to the same test, add smart folders to the test case and organize the modules in them. Smart folders also make it easy to exclude particular parts of a test case from being run during test execution. This is exactly what we’re going to use a smart folder for in our example. We might not always want the validation to be carried out, so it will get its own smart folder. To add ValidateEntries to a smart folder:
Right-click the test case SimpleDatabaseTest and click Add > New smart folder.
Drag ValidateEntries to the new smart folder.
Rename the smart folder to Validation.
Excluding items from a test run is explained in Ranorex Studio fundamentals > Test suite > ⇢ Execute a test suite.
Our test is almost complete. We only need to add the last step, exiting the Ranorex Demo Application. This is a perfect example of a step that should be in a global teardown region because, after it, no other test actions can be performed. The system is restored to its state before the test. Normally, this would also include deleting all entries made, but our database doesn’t save any entries when exiting, so we don’t need to include this action. To add the teardown region:
In the test suite view, right-click the test suite and click Add teardown.
From the module browser, drag the module ExitAUT to the teardown region.
Congratulations, you’ve just built a test in the test suite. You can apply the basic principles of this tutorial to any other test you’ll create.
This is the point where you’ll run your test. We’ll cover the details and advanced options of running tests in the next chapter. For now, just press the large RUN button in the test suite view and enjoy your database test executing!
Running tests is explained in detail in Ranorex Studio fundamentals > Test suite > ⇢ Execute a test suite.