Reuse Testcases
Make it possible to use a testcase more than once in a testsuite, just as it is possible to reuse a recording or code module. This would allow more modular use of testcases.
Andreas Grasmüller
shared this idea
Thank you all for your input.
Starting with Ranorex 9.3, you are now allowed to use non-unique names for test cases and SmartFolders. This isn’t as good as really having full reusability of test cases (I know), but it should help you in some instances. For example, having the “same” SmartFolder in several places now is easier, you don’t have to rename them after copy/pasting them.
Best Regards,
Thomas from the Ranorex Product Management Team
15 comments
-
Anonymous
commented
If it is not possible to reuse/instantiate a Testcase, maybe it is possible to reuse a SmartFolder? Just being able to reuse names is small potatoes, and will interfere with existing solutions that work with code that specifies Testcases by name. You could also soup up Module Groups by allowing Smartfolder-like structures (IF-capable) in there.
-
Anonymous
commented
at least reusing the same name would be helpful
-
Marcel Zerdin
commented
In my line of automation I am automating different scenarios always with the same steps - TC.Instead of writing one TC and then referencing/using it in my test suite at different places. I copy pasted the TC and rename it with adding maybe a "_1", " _2" or I use some other suffix.
-
Christian
commented
It would be very convenient to reuse smart folder names.
-
Heather
commented
I agree! I'm not sure if this is exactly what you are getting at, but I find it inconvenient and unorganized to repeat a smart folder in multiple test cases only to have to name it differently each time.
-
Andy Simpson
commented
I concur that this scenario would be very useful as it would allow the smart folder naming convention to be as succinct
-
loonquawl
commented
better yet, make it objkect oriented at that level, so same name is same entity, and you don't have to alter 99 copies of the same part of a test (that part of the test may not be simply packable to a recordings-group, as there may be data-sources, IF-dependencies et al)
-
loonquawl
commented
Better yet: make them object oriented, so same-name entities will actually be same
-
Motomu Ito
commented
In different hierarchies of a test suite, allow users to create TestCases(or SmartFolders) with the same name.
-
loonquawl
commented
Would be very convenient to just use an instance of a Testcase, instead of the Testcase itself.
Would make everything much more easy to alter and service - especially if the user gets some say on the instance (have an instance of the testcase somewhere, in studio show that TC as it is, with checkboxes pre-enabled for every recording and module, so you can disable individual modules in that instance of the TC)
It would be like a cool module group, because module groups have that instantiation-goodness, but lack loopability and the possibilty of SmartFolders (which would provide conditionality) - the dis-/enabling of individual modules would just be another convenient twist on the general idea.
-
Uwe Matzen
commented
I agree as well. At the very least, SmartFolders shouldn't be required to be unique; or they could have a "Display Name" property that the TestSuite folder can be configured to display instead of Id.
-
Pavel Kudrys
commented
There is already a feature request for this:
http://uservoice.ranorex.com/forums/150109-ideas-to-improve-ranorex/suggestions/17132710-reuse-testcases
And it's something Ranorex folks already considering ;) -
Uwe Matzen
commented
Completely agree on this. I understand why testcase names should be unique,but with the addition of Smartfolders in 7.0, i becomes possible to simulate testcases with multiple configurable steps. But being forced to give them uniqiue names is pretty inconvenient.
-
Anonymous
commented
would be helpful if we could name different TC's in one TestSuite s same if the TC's are located in different folders
-
Pavel Kudrys
commented
Absolutely agree here! I often use the same TCs across my solution, but each TC needs its own unique name. And this is a real pain, because I often do same TC name-based magic in code (like enabling/disabling TCs or setting TC data range), which means I must not to forget to add each single TC name to my code ;)