Hi,
I have a suite which consists of only Images. I want to access these images from a script in another suite. I have added the suite with images as Helper to the suite which has scripts, but i’m not able to neither view the images in the new suite nor able to access these images.
How do i access images from another suite?
Thx in advance.
-Veena
To access images from a Helper suite, refer to them in your script the same way you would if those images were in the local suite. So, for example, if you have an image named “OKButton” in the top-level Images folder of your helper suite, you should be able to click it like this:
Click "OKButton"
When Eggplant executes this command, it looks first in the local suite (the one where the script file is located) for an image named “OKButton”. If the local suite doesn’t have such an image, Eggplant looks in each of its Helper suites (as listed on the Helpers tab of the suite) in the order in which they are listed, to find the image to use.
Keep in mind that if you have an “OKButton” image in both the local suite and the Helper suite, Eggplant will use the local image. Also be aware that the Images tab of a suite only shows the images in that suite, not in any of its Helper suites.
Doug,
This bring up an interesting point that I have been thinking about lately. Is there was good way to over ride this behavior. This is the reason I ask.
I have found that during our product development cycle each major release might render some part of the product slightly different. If we just update the baseline for the new result we can’t go backwards succesfully. I am trying to figure out the best solution for this.
Any thoughts without too much information on how you will deal with something like this so you could for example look in a different path depending on a variable that is set?
~Charles
Just to give a little more details about our current structure.
We have basically two major test suites.
Browser test suite - i.e. Safari
This test suite sets up some global information related to the test run and helps to call the interface to be tested.
Testcases test suite.
This is where all of the test case files and releated images are. There is no real structure here.
Based on my previous post everything is funnelled into using this default image directory path unless something else is hard coded. I need a way to duplicated this database of images for a new project without having to update all my test cases with the new path. Maybe a way to tell eggplant if the global var “Codename” is set to X use this path?
Help and or ideas appreciated.
~Charles
Right now you can’t put a Suite higher in the precedence than the local suite. What we typically recommend in this scenario is to put your base images in their own suite and include that helper by default. Then if you want to test with override images add another Helper. We would like to improve on this behavior in future releases of Eggplant and give more control over the Suite precedence.
You bring up an interesting approach though, you could have a Global variable “ImagePath” and then in your code do things like:
click global ImagePath & "image01"
Then if you set global ImagePath to “~/Suites/OverrideSuite.suite/Images” it should work for you.
Charles,
While it may not be obvious, Eggplant actually has two Helper suite mechanisms that have different strengths. Working with different sets of images is what the “dynamic Helper” mechanism is designed for. The following description of the two types of Helper suites may help you to understand this a bit better.
Static Helper suites – those listed on the Helpers tab of a suite – are especially good for including libraries of utility scripts that may be useful in a number of different suites. Simply list these utility suites on the Helpers tab and all of their scripts and images will be available to every script in your suite.
On the other hand, when your script needs to dynamically determine which “Helpers” to use at runtime, use “dynamic Helpers” – the OpenSuite command – to choose which suites to make available as helpers. One of the best ways to do this may be to create a master controller script that first opens your helper suites and then calls your test script.
Here’s an example controller script that looks at the screen to see what type of SUT it’s connected to and chooses the appropriate suite to open to use images for that platform:
// Master script -- opens appropriate helper suite and then runs test
if imageFound("AppleIcon") then -- (if the apple's there, it must be a Mac)
set platformName to "Mac"
set the currentTextPlatform to "MacOSX_10.4"
OpenSuite "MacApplication"
else
set platformName to "Windows"
set the currentTextPlatform to "WindowsClassic"
OpenSuite "WindowsApplication"
end if
LaunchApplication "MyApplication" -- launch our application
MyApplicationTest platformName -- pass the platform name to the test script
This hypothetical example would be used for testing a cross-platform application that could be running on either Mac or Windows. The main test script (“MyApplicationTest”) drives the application on either platform, even though some images may be different for the two versions of the application.
There are a few valuable points to note here:
By opening either the MacApplication or WindowsApplication suite, we make the images from one of those suites available to all of our scripts. If the two versions of a given image have the same name in the two platform suites, your script can simply use the image name in a command – Click “OKButton” – and the appropriate “OKButton” image will be used.
Images that are the same for both platforms can be stored in the main suite. For example, if your application has a “PrintReport” button that uses the same icon for both the Mac and Windows versions, you could keep a single copy of that image in the main suite.
In addition to images, the OpenSuite command also makes any scripts in the suite available, allowing you to create scripts to deal with platform-specific behaviors. For example, the process for launching an application may be different on different platforms. In our example, if each platform suite has its own LaunchApplication script, the LaunchApplication command shown in the script above will call the script in whichever suite is open.
The script above also sets the currentTextPlatform global property to the appropriate platform. For generated text images, this allows your script to use a text style that may be defined to use a different font or other characteristics on the the two platforms.
At present (at least up through Eggplant 3.31) any suites opened by the OpenSuite command are automatically closed when the script or handler that opened them exits. This means you’ll need to use the approach shown here of opening a suite and then running your test within that same script. Your test script can’t call out to a utility script that opens the suite and then returns, because the suite will be closed before execution resumes in the test script. We plan to enhance the OpenSuite mechanism in a future release to provide more flexible options, but for now you’ll need to design your scripts to work with the current behavior.
This example used the OpenSuite command to deal with using the images and behaviors needed for the Mac vs. Windows versions of the same application. The same approach can be used, however, for testing a web application running in different browsers, for testing an application localized in different languages, or for testing different versions of your application.
In your case, if you move all of your current images out of the main suite into a dynamic helper suite, then adding an OpenSuite command at the beginning of your test scripts should allow them to continue working as they always have. Then you can make a copy of the helper suite and change any images in the copy as needed for your new project. At that point, to switch your test between the old and new versions, simply change your test script to open the other suite in your test.
I hope this helps!
Both of your replies help very much. It’s hard to figure out how I am going to encompass it all into our current architechure but I’ll figure something out.
Thank you for taking the time to give me some possible solutions.
~Charles