There are many different possibilities for organizing a Ranorex Studio test automation project. The main goal when doing professional test automation with Ranorex is to create reusable automation modules. This can be realized by distinguishing between commonly used automation modules which perform actions like starting an application and specialized test modules performing a narrowly defined task.
The test project solution consists of:
- an executable project (command line project)
- a project related library project (.NET DLL)
- and a commonly usable project, which can be referenced by other test projects
EXE Project â€“ â€˜Executionâ€™
The executable project specifies the test cases of the solution and defines how each test case is triggered. Additionally, a â€˜Setupâ€™ method initializes the system under test (e.g. starting the application) while the â€˜TearDownâ€™ method cleans up the system be-fore the next test case is started (e.g. closing an application). Each test case is implemented within single files and classes:
The test case refers to the â€˜AddVipâ€™ recording which is part of the â€˜VipTestLibraryâ€™ DLL project. To reuse a method or class implemented within another project, a reference to the project has to be added.
Library Project – â€˜VipTestLibraryâ€™
A library project can be created by adding a new project to the solution. The project template â€˜Ranorex Class Libraryâ€™ is part of the â€˜Advancedâ€™ folder shown within the â€˜New Projectâ€™ dialog wizard.
The reason for having a Ranorex class library is to manage the modules (recordings or pure code based classes and methods) separated from the execution project. All recordings are stored within the â€˜Recordingsâ€™ folder while the modules, totally based on user written code, are part of the â€˜Codeâ€™ directory. Also the repository, which manages all the UI elements of the application under test, is part of the library project.
Common Class Library â€“ â€˜Commonâ€™
Itâ€™s not required to have an additional library implemented to handle common methods like starting or closing the system under test. Regardless, when thinking about other test projects or solutions which require a common method like killing a process in order to shut down an application in cases of errors, it would be good to have one robust mechanism for that purpose. In comparison to the â€˜VipTestLibraryâ€™, the â€˜Commonâ€™ class library project does not have any information about the application under test. Everything required for UI automation is provided by parameters.
Add the â€˜Commonâ€™ library as reference in order to reuse the classes and methods implemented within it.
Test Case Execution
In that example the execution is triggered by a simple batch file, which specifies the execution sequence:
cd bin\debug call execution.exe -tc addsinglevip call execution.exe -tc savevip call execution.exe -tc connecttodatabase
Itâ€™s possible to evaluate the return values (FAIL=-1, SUCCESS=0) at the command line interface as well. In addition a command line based execution is supported by many test management tools. That helps to ease integration of Ranorex tests into existing execution environments.