I tried to search the forum and site for an answer but couldn’t, hence this post. Excuse me if this has already been answered.
Eggplant is primarily based on recognizing images (which may contain text) for scripts to run smoothly. So, does v3 still rely on this?
Just by the name of the feature, I assume it’s an ability within an Eggplant script to generate picture files that contain text. Am I under the wrong assumption? If my assumption is correct, then how does it really help because most of the problems I face is simply scripts not recognizing images and maintainability if the look or feel of a web application has changed.
A list of new features/enhancements for v3 would be appreciated.
Eggplant 3.0 does indeed add the ability to create Images just by specifying the text string and various font attributes. This provides a number of benefits to Eggplant users.
Previously, changes to the fonts of an application or website would force Eggplant users to recapture images that used Text. Starting with 3.0 for scripts that use the new Text Image Generation feature sSmply changing an Eggplant font style definition will allow Eggplant to re-render all of those images that are just text.
Another huge advantage to the Text Image Generation capability is the ability to render dynamic text that would be difficult to capture ahead of time. Now if your script retrieves a value from a database or from your SUT you can render the appropriate text to find it on the screen.
Font attributes? Can you specify color, size, italics, underline, bold, and background (including a custom background and not just a solid color)?
Yes to everything except a background image (only solid colors). Also underline has the caveat that hyperlink display in many browsers is NOT done by adding an underline attribute but is instead a separately rendered graphic element.
Automatic text image generation is extremely quick for Mac OS X rendered fonts. It requires a little setup for Windows but it is also very quick.
I see the benefit of rendering “text that would be difficult to capture ahead of time”.
But if you don’t need that, then I don’t see the benefit of auto generation really. Since you have to know ahead of time what font attribute needs to be applied to generate text image at run time, when the web page look changes, you still have to go and update the font attributes in the script to match the new look/link (similar to having to capture a new image anyway).
Also, if you’re trying to match text on non-solid background then this new feature won’t help. Maybe I’m missing something.
I’m coming from a place where I want to make the least amount of changes to a script for it to continue functioning after a web application has changed.
For example: I could match the first text field on an online form, then tab and use text input to fill the form instead of capturing images for each field. But even the submit button is sometimes not detected. I know capturing an image for each input field is maybe better because if a field is moved, the script won’t break. But I find the whole image match/verification is very buggy no matter what the tolerance setting is. One minute a script will find the image, and the next it doesn’t (without changing code).
We believe the new Text Image Generation capability will be a tremendous help to many Eggplant users. But of course it won’t be a complete solution for every situation. If the text in question is displayed on a non-solid background you will still need to capture those images as in the past.
The ability to define Text Styles allows you to make a single change to alter every use of a given style in your scripts – much better than having to recapture every image of a menu item (as one example). Our goal is to make Eggplant both easier and more powerful with each new version.
Please be patient, and give these new capabilities a try when they become available. Then we would love to hear your comments about how they can be made even better – which you can send to us using the newly-improved direct feedback mechanism in the new version. We will provide full details on all of the new features when version 3 is officially announced.
In the meantime, if you are having difficulty finding images in your script, please send email to support, and we’ll be happy to help resolve the problem.
“Please be patient, and give these new capabilities a try when they become available.”
We have been. But it doesn’t help to be patient when at the same time you need to get tests done and the tool you’re using can’t be relied upon to give accurate test results (or even finish running the scripts to their conclusion).
“In the meantime, if you are having difficulty finding images in your script, please send email to support, and we’ll be happy to help resolve the problem.”
We’re not having difficulty of finding images in our scripts. It’s Eggplant v2.22 (and earlier) having difficulty matching the images in our scripts with the actual web page application at run time. Scripts constantly stop/break because of this.
Anyway, I appreciate the responses and good luck on your version 3.
The problem you describe sounds like a timing error that is especially common to testing web pages. In my experience it is extremely rare that Eggplant won’t find an image correctly. You may want to experiment with additional validation techniques (perhaps after each major step), similar to what a human being would look for while performing a manual test.
As an example, a script could request a web page but not wait long enough for the page to load entirely before continuing with the rest of the script. In this instance, since the script is not validating the state of the SUT before taking action, the script will eventually fail or complete “successfully” while not actually performing the intended test at all.
The Eggplant 101 class shows how to avoid this problem, as well as many other useful concepts and techniques. More information about the class can be found here: http://redstonesoftware.com/training.html