Add a recording module action for calling another recording module including databinding if needed
Add a recording module action for calling another recording module including databinding if needed.
For me as Testautomation Engineer it is not that difficult to write some Usercode to do this but for a Tester with no programming language background it is not.
e.g. : In our application we searching for medicaments, after a successful search we can do several actions with the search result. Therefore this search operation will be used many times and I sepparated this to sepparat recording module that consums the medicament as a parameter. If you do not want to use a user code action for calling this module, the only possibility is to split a testcase in several recording modules so you can use the search module between. So you will be forced to create some "dummy" recording modules. That is not very comfortable and during the time not maintainable.
This would be useful for me too. I have an example situation where this could keep my test cases tidier as follows:
Action 1: Click a save/export button in the AUT.
Action 2: Call into a "Complete File Dialog" generic recording (with bindings passed through).
Action 3: Wait for some GUI progress element to complete.
Currently the above would require 3 recordings, 2 of which are single actions and would spam my test suites with unnecessary steps that would be tidier in one recording.
I currently do this in user code but as the OP says, other testers are not comfortable with user code.
I would recommend caution with this however. I recently refactored my test solution to split it out into multiple repositories and used the user code calling of other recording as a bridge to to call into multiple repositories in the same recording. I am now going through and in most cases splitting the recordings to remove these calls due to the added complexity and confusion it can cause with re-routing of bindings (and decreased flexibility).
Best practice is definitely to have separate recordings and add them to test cases/smart folders or module groups to combine their functionality.
how is that different from putting both the search-recording and the do-something-recording into a smart folder that binds their variables together via a parameter?
Hubert Marxer commented
would be useful to build small recordings iI can use as a base for other recordings
Tobias Scherzinger commented
In certain aspect with in a business process you want to change the databinding dynamically base on a filter or search result. This filter or search result is created with a recording module that runs some user code to dynamically change the databinding.
This databinding is then used by the following recording module in the same test case. To do this without this additionally recording module, with user code in it, it would be more comfortable to do this as a recording module action which calls the following recording module with the needed databinding.
Christoph Schudel commented
I would use this option too, if it was available. Often I create a number "mircro" recording that I put together in a "bigger" recording. With this approach I can create a number of "bigger" recording that differ slightly, using only selected "mirco" recorgings.
The use case is this: When testing certain aspects within a business process some setup steps need to be done. When testing another aspect of the business process very similar setup steps need to be done. That means some setup steps are needed in both processes whereas others may differ. For example for one process a value in a drop box must be set to a particular value whereas in the other process the value of the dropbox is not relevant and therefore does not need to be set. So it would be very nice if the "micro" recordings could be called by a "bigger" (mother) recording. I'v done it a number of time in code, but it would be easier to read if it could be done straight as a recording action.
Thank you very much for your input. What's exactly the reason why you would like to do this on a recording level, rather than on a test suite level? Later option would offer you data binding for different search terms as well.
Ranorex Product Management Team