searching current screen

Hi

Is there any way that I could have a quick search to see what screen I am at?

Here is what I want to do. I want to implement the cleanup function which will reset my app to startup screen whenever I got an error in my testcase. Then I am able to run the next testcase. My problem is how do I know which screen I am currently at so that I could cancel the current task and logout?

If you could give me an example script, it'd greatly appreciated.

Best Regards, :cry:

Comments

  • I don't think Eggplant has a feature that can tell you which screen you're on.

    I think that has to be something that you do yourself.

    Here's what I do to track my application's progress. I am currently writing smoke tests for my team.

    I do this two ways. There are about 10 pages that are core to the application (basically portals to other pages).

    I created a bunch of functions that had knowledge about these pages (images that identified the page - around 2 for each page is what I use), return hotkeys that help me navigate to the page, etc.

    Here's an example of what I'm talking about.
    
    [b]Script - fe_object_mail[/b]
    
    
    function getHotkey
    	return "\ag\App\r"
    end getHotkey
    
    function getImgs
            return ("mail_img1", "mail_img2") 
    end getImgs
    
    

    Now this is something that I spent a couple of days doing. If you prefer to copy paste code (not recommended) then just search for the images whenever you want to double-check your location.

    The second way would be simply to search for certain images at a given point.

    I perform a search for the images that identify my page using the waitfor (when I want to give the application a few seconds to load), imagefound, click (when I want to find the image on the screen quickly) and, imagefoundnow (when I know where the image is supposed to be every time and want to find if it is there immediately)
    
    try
         -- Wait for application to go to page/ wait for a form to load
         waitforall 5.0, "img1", "img2"
    
         -- click on images to be found (If you don't fancy waiting too long for
         -- the image
         -- used if I'm not sure if the image is going to be in the same place    
         -- every time 
         click "img1"
         click "img2"   
    catch
         (*   do something to handle an image not being found                 *)
         (* I write to a log indicating failure of the test, and increment the *)
         (* number of failures, take a screenshot of the screen, and,        *)
         (* restart the application                                                          *)
    
         -- I have a script with functions for logging. The scripts below
         -- Increment the number of failures for my test, and, 
         -- add the name of the test that failed
    
         [log_function incrementFailureLogFile:]
         [log_function addFailureNamesLogFile: sScriptName]
    
         -- The script below takes a screenshot, force kills my application,
         -- and logs back in to the application
    
         fe_exception_close_fe_log_exception_open_fe sLogFile, sFELocation, sLogin, sPassword, "*** FAILED ***  Test", "py_config_new_schedule_not_added"
         
         -- I break each test component into seperate scripts, so I exit from
         -- the current script (running the test) so I can continue to the next test
    
         exit me
    
    end try
    
    

    Now to explain my structure.

    I have a driver script that calls my test cases. Each test case is in a sepeate script of its own. I've tried to make the code as reusable as possible using scripts that reside in their respective suites to reduce my dev time.

    Each test case runs through a bunch of operations. I have a try catch statement anytime I expect to find myself in a certain location, or, I am looking for a certain label or do something that I want to mess up (negative testing).

    I have log functions that do a number of operations... I have a status log, that I poll to find out where I am in my testing process (using apache and shell scripts... ppl seem to find browsers much less intimidating to use than using the UNIX command line), a debug log that basically logs everytime I want to do something specific (at a higher level than the log provided by eggplant), mainly important steps in the testing process, whether a test has passed or not, and of course the all important summary that tells me about my run.

    Hope you find this useful. If you would like more examples I'll see what else I can help you out with.
  • bharathh,

    Thanks so much for your responded. Currently, my application has about 35 screens and about 100 notified, warning, errors popup dialogs. If I do search image, by default, the search image time is 1.80s. Let multiply by 135 images........243s....do you think there is the performance issue? Is there anyway that I could minimun the search time without reset the default search image time from EggPlant preference?

    Anybody has faced similar issue. Please share your expericence.....
    Thanks,

    Best Regards,
  • JonathanOSXJonathanOSX ForumAdmin admin
    Buffalokml:

    There are several ways you can do "quick" searches for images that don't wait for state to change on the SUT, a good example is in our Examples code section:

    http://www.redstonesoftware.com/phpbb2/viewtopic.php?t=32

    You can also give the imageFound() function an optional time argument (although there is a minimum amount of time just to get screen synced and to make a one pass search).

    if imageFound(0.3, "myImage1", "myImage2", "myImage3"...) then ....

    Even with those optimizations it's going to take a while to search for that many images. What we do here at Redstone is usually try some basic recovery techniques. IE in a loop we close windows by hitting Cmd-W or clicking the Red Circle if the window doesn't want to close then we hit the escape and/or enter keys and try again.

    Finally we have a script which ctrl-clicks on the app icon in the dock, then holds down OPTION and force quits the app, then you know your good to go with the next test.

    The solution really depends on how you would want/expect an end user to "get out".
  • You also have the option of skipping a couple of screens - that are less process oriented and concentrate more on the screen that you would like. If something messes up, the logs are available to trace through.
Sign In or Register to comment.