Guidance on image storage

I have a web based application (shopping cart) that I have to test. I need to test with six different browsers, with all credit cards accepted (Visa, MC, A.E. etc.), and all languages (we support). This needs to be as automated as possible (since there’s lots of tests to run).

I know how to call one script from another, functions, and basic helper feature. I’m also aware of your image naming convention recommendations (i.e. pd_ prefix for pull down image).

How should I organize and name all the images to make them easily accessible for each variation of test runs? In other words, do I name them like this:


for safari, netscape, and internet explorer Name text box image. I’m not sure how many images are really reusable across browsers (when I save the image as “text” instead of “Tolerant”).

Then I was thinking of using the images like this:

Set prefix to “sf_” – Set at start of script

WaitFor 60, prefix & “tb_Name” – use the prefix

The language could be incorporated in with the filename too perhaps:


This eggplant approach seems so labor intensive. Having to capture images 'n all.

You can also use helper suites to organize your images. You can read more about how this can be done here:

Well it helps and it doesn’t. I just don’t know the best way to go about tackling my task.

I have to deal with different browsers, different OS (Windows, Mac), different shopping cart color schemes, different languages, different credit cards. I’m trying to think of the BEST way to organize this.

I would start off by recommending the Using Eggplant manual.

The articles should help a great deal:[list]Organizing Your Images
Scripting for Localization and Multiple Operating Systems
If you have specific questions beyond that or feel that we should add more to those please let us know.

Thank you for responding.

I read those sections from the manual before. Your manual suggestions are to use the same image names but call each suite differently depending on the task (like englishimage.suite, germanimage.suite, etc.).

That means a lot of suite files. How do you handle naming five levels of test scenarios? As mentioned, I’ve got OS, Browser, Languages, Credit Card types, and various currencies. How would you specifically organize them?

Thank you.

First Analyze the Problem
There probably isn’t one single approach that you’ll want to use for all of the things that are varying in your tests. You’ve obviously given this a lot of thought already, but I suggest you start by thinking about which things are dependent on each other and which are independent.

If you think of your five variables (OS, Browser, Language, Credit Card, Currency) as different axes, then you’ve got an enormous grid of possibilities for all of the possible combinations of different values (e.g. Mac OS X, Safari, English, VISA, Dollars). But not every possible combination here is going to be useful or valid.

Take Credit Card, for example. Does your test need to be different somehow for testing the use of a VISA card in English versus when you’re testing in French? What about when purchasing in dollars vs. pounds or euros – does the VISA icon change? is the ordering process different?

Hopefully you can eliminate some of the possible combinations, which will simplify things considerably. If it turns out that credit cards are basically independent of the other variables, then you can probably get away with simply creating a list of credit card types and iterate over them in the appropriate place as needed.

Then, Put it into Practice
Turning to the practical question of how to implement all of this, there are a number of techniques available that may be helpful.

Using an Eggplant suite has the tremendous advantage that it carries both scripts and images. This makes it an ideal mechanism to use when a lot of things – especially images, but also some behaviors – will be changing. So, for example, we recommend creating separate suites for use with different operating systems, since most programs being tested look somewhat different on different OS’es, and there are usually some behavioral differences too (such as native file-selection dialogs) even when the basic application behaves the same on both systems.

If there is another aspect of your system that has a similar level of variability, you may want to consider using suites for that aspect as well. For example, if many of your images will be different depending on what language is being used, it may be simpler to use different suites for each language. That way the image names don’t change – you just use the openSuite and closeSuite commands to select the appropriate suite and suddenly you are working with your German images instead of the French ones without changing anything else in the script.

The drawbacks to using suites are that they can be difficult to manage if there are a lot of them. If you use suites for both OS and Language then you will likely MacFrench and MacGerman and WindowsFrench and WindowsGerman suites, plus all the other combinations. For a lot of languages and OS’es it can get cumbersome.

Image Names
Another technique you can use is to name your images appropriately within each suite. You’ve already mentioned using prefixes on your image names. To further help with the organization of your images, you may want to create subfolders. For example, if some of your images vary based on the browser, you might create separate subfolders for Safari, IE, FireFox, etc. You’ll still have to include this part of the name when you access the image in your script, but you may find it helpful when working with the images themselves to have them grouped in this way.

Using Functions
As for accessing the images in your scripts, a combination of global variables and functions may help to simplify writing the commands, especially if more than one prefix may be involved. Take the example you used earlier:

Set prefix to "sf_" -- Set at start of script 
WaitFor 60, prefix & "tb_Name" -- use the prefix 

Instead of doing it in quite this way, you might consider something like this:

global Browser, Currency, CreditCard
set Browser to "Safari"
set Currency to "Pound"
set CreditCard to "MasterCard"
WaitFor 60,bccImage("tb_Name")

Now you can write a bccImage function (I called it that because it incorporates the current browser, currency and credit card settings) that assembles the image name any way you like. For example:

-- bccImage function --
params imageName
global Browser, Currency, CreditCard
set ccPrefix to property (CreditCard) of (Visa:"vs_", MasterCard:"mc_")
set curPrefix to property (Currency) of (Pound:"p_", Dollar:"d_")
return Browser & "/" & curPrefix & ccPrefix & imageName

The exact details of how you assemble the image name from the various pieces is up to you. The function above assumes the browser name is a subfolder of the Images folder, and uses abbreviated prefixes for currency and credit card. You can even get more sophisticated about it if you like, such as omitting the currency prefix if the image name passed in starts with “tb_” (or whatever).

You’ll need to decide what the rules are, though, before you go capturing all of the images, so you know what to name them, and where to put them. And yes, it may end up being a lot of images. By calling a function to return the name of each of your images, your script will be modular enough that it should be easier to adapt as your needs become clearer or requirements change.

You’ve got some complexity in the project you’ve been asked to test, but by simplifying it wherever you can and using some of these techniques, hopefully it will be more manageable.

If people have tried other approaches to this sort of thing, please post your experiences here, too, so everyone can learn what has worked (or not worked) for you. Different approaches may be good in different situations.

Thank you very much for taking the time to share all that.

I actually have thought of using the browser, currency and credit card variables idea already, but didn’t really think of using a function to return the image name. That’s an intelligent approach.

Quite honestly, I don’t think I’ll use egglant for this type of test when all I really need is to verify the HTTP protocol request and response headers and data. I can use eggplant for testing the visual template themes of a site.

Although I still might end up writing the scripts in eggplant, we are looking at other test tools that will just handle more form based (raw HTTP) tests than visual ones. Someone at the office mentioned HTTPUnit, but I noticed it has 103 bugs listed and no release since late last year.

If anyone else has any ideas on an approach, or has other HTTP testing tools that complements eggplant, please post it here.

Thank you.