I’m new to eggplant and I inherited a script that has a line:
run
The other script is in another directory and there is no path command or any other lines before this. The script runs fine unless I move it to another folder. How does it know the path to the other script? The eggplant documentation says:
Run Command
Example: Run “OtherScript” ,“parameter1”, “parameter2”
Parameters: One script name.
Behavior: Calls another script.
That’s not very helpful. Is there any better documentation?
You don’t need a path as long as the script is in the current suite or in a Helper suite, the InitialSuites, or the FinalSuites; each of these mechanisms adds the referenced suites to the current suite’s scope. If you really want to reference a script that’s not part of the current suite’s scope, you can specify a fully qualified path to the script. If you’re using the Mac version, you can just drag a script (or any other file) to the Script Editor window from either another Suite window or a Finder window and eggPlant will automatically insert the path, but it’s generally easier to use one of the above mechanisms so that you can just refer to the script by name.
Also, note in the command description that for most scripts where the name does not contain a space, you can call it with just it’s name – there is no need to use the Run command.
Hello Matt,
Sounds good, but what if there are e.g. 5 suites attached to my master suite and there are scripts with the same name?
e.g.
Suite1.suite/Scripts/Testscript.script
Suite2.suite/Scripts/Testscript.script
How can I differentiate them?
Well, the short answer is that you just shouldn’t have that situation. The only reason to deliberately have scripts with the same name is if you want to be able to override the behavior of the script via the InitialSuites mechanism. Having two scripts with the same name in more than one helper suite is just not a good design and there is no way to differentiate them unless you specify the full path to the script when calling it, which negates the value of the Helper Suite mechanism.
To concur with what Matt said: If you are doing operations where you want to control the order that eggPlant will find a called script then we recommend using the initialSuite and the finalSuite global property lists (as described in Eggplant Rerence and Using Eggplant). Those lists will be evaluated in-order before and after the current suite, respectively. Additionally, you have complete control of those during your script’s run.
For helpers it’s a bit trickier. Although helpers are queried for scripts in the order they are listed on the helper tab they ALWAYS are checked after the current suite. If you are already running a script in another suite then it may also have helpers (again which are checked AFTER that suite for scripts). All of that means you can quickly end up with a very complex helper loop where it will be difficult to predict precisely which script has precedence. So helpers are good for “helping” by offering utility scripts. But they aren’t ideal for overriding scripts with other scripts.
Hope that helps clarify the situation.
I see. Our SUT is broken up into several modules and every module has a separate login mechanism. My idea was to group the testcases into suites according to these modules and execute all of them from a master suite.
Like:
Module1.suite/Scripts/Login.script
Module2.suite/Scripts/Login.script
I don’t see the point why it is a wrong design but okay…I’ll rename those scripts.
Anyway, could you please answer my question here too: http://www.testplant.com/phpBB2/viewtopic.php?p=6816&highlight=#6816
The flaw in the design is if you are going to add both suites as Helpers, since whichever Helper gets added first will hide any scripts with the same name in Helpers added after. If you don’t add these suites to your main suite as Helpers or by adding them to the initialSuites or finalSuites, then you can call the specific script that you want to run by specifying its path in the Run or RunWithNewResults commands.
If you use the initialSuites approach you can change which suite is used on the fly:
Set the initialSuites to ("SuiteA")
Login //will run the Login script in SuiteA
Set the initialSuites to ("SuiteB")
Login // runs the Login in SuiteB
I recognize that you may be working with an existing framework that is just something you have to make do with, but if you are creating this set of tests, let me suggest an alternative approach: Let’s assume that you want to run this test against a Windows SUT and a Linux SUT. The approach that I would suggest is to create a suite to run the test against the Windows SUT and have this be your main suite. Let’s assume that your Windows suite has scripts called Login, CreateItem, and Logout as well as a Master script that calls these other scripts as appropriate. Then create a Linux suite that also contains scripts called Login, CreateItem, and Logout, but of course implements the Linux specific steps for those actions and has images captured from the Linux SUT.
Now when you want to run your scripts against Windows, you simply run your Master script and it calls all the scripts in your Windows suite. When you want to run against Linux, you put the following line at the beginning of the Master script:
set the initialSuites to ("Linux")
and when your Master script calls Login, CreateItem, or Logout, it will be calling the versions of those scripts that reside in the Linux suite.