How to handle frame identification in iTest4.1 GUI
Hi Group,
In my Test case I want to open multiple 3panel forms and need to close corresponding forms. When I am trying to close the 3-panel forms, iTest4.1 captures as follows where as the "Frame number" is not constant all the time.
//RedCellManagedObjectDefaultEdit[@name='frame4']/rootPane/layeredPane[@name='null.layeredPane']/panel[@name='null.contentPane']/panel/panel[2]/panel[1]/panel/button[@text='Close' and @tooltip='Discard changes to this managed object']; left
Issue: - This frame numbers not a unique number. It is changing randomly while executing the test case. Because of this issue my test case failed.
How to handle multiple 3panel forms at a time?
So please anyone can help me to solve this issue.
Thanks in Advance
I'm not an expert. But I believe that in these cases where you have truly dynamic content on your web page, you need to study the DOM of the page (use "snapshot") and try to figure out how you can uniquely and consistently identify the object that you want to take an action on. A good starting point is to ask yourself how you know which one of these things you are operating on when you're clicking on the web page. "How did you know to choose that one versus that one?" The answer to that question will usually tell you how to choose the appropriate target. The most iTest can do at capture time is to try to make an educated guess when there is that kind of redundancy.
Did you know that targets are just XPATH queries? So when you look at the output from snapshot, you are looking at an XML document describing the page. You can use any XPATH query you want as a target -- as long as it will lead to the object that you want to take action on. XPATH is very powerful, so if there is a way to distinguish your object, you should be able to express it in XPATH.
There is a new feature in 4.1 that allows iTest to connect to an existing swing session. We have a fundamental issue with iTest on the record and replay operation. We expect iTest to record and replay java swing applications, especially opening and closing GUIs, with no workarounds.
This operation works great opening frames but closing frames iTest has an issue. iTest identifies each frame by number (1,2,3...). If we keep the session open iTest keeps incrementing the frame number (...,10,12,13...) for the command that closes the frame.
We finish on test and close GUIs (frames 1,2, & 3) and start another test. We go to replay, open new GUIs and iTest tries to close frames (4,5, & 6) and throws an error. Only frames 1, 2 & 3 are open.
iTest needs a better way to recognize frames that need to be closed. I recommend the iTest use an additonal property to close a given frame like window title.
We plan on creating a quick call that will close open frames but this is a workaround solution.
Thanks for sharing your experience with this. We'll take a look....
Thanks Mike for the information. I will take a look at our implementation and get back to you.
I see your point. the frame number keeps increasing, and this is a problem since you keep your swing app always running, so the target generated by capture will not match the frame number the next time you replay. The frame number is a java swing feature. iTest is using it by default to identify the window.
I also agree with Paul that in cases like this, you need to study the structure data and see if there is a different way of uniquely identifying the window.
You can take a snapshot, which will return an XML representation of all the visible windows in your application. This XML representation is the structured data and you can use Xpath to build your own target.
For example, if you always know that you will have three windows with the same title open at a given point in the test case execution, you can use the title attribute plus index number to identify the window that you want to close. Suppose I want to close the first window, try the following target:
//RedCellManagedObjectDefaultEdit[@title='my title'][1]/rootPane/layeredPane[@name='null.layeredPane']/panel[@name='null.contentPane']/panel/panel[2]/panel[1]/panel/button[@text='Close' and @tooltip='Discard changes to this managed object']; left
Here is the tricky part. Now that you've closed the first window, and you want to close the second window, you may think that the target to do this is @title='my title'][2]. That is not correct. The target is again @title='my title'][1], because there are now only two windows open, and you want to close the first one out of the two.
You can always close the windows in the reverse order. Starting with @title='my title'][3] and working backwards to [1].
I think the frame number identification is going to create a lot of issues for iTest users. We have some users that are very skilled at using iTest and will work around this no problem. Other users are going to be frustrated since they have to manipulate the frame and title information to get their test cases to run.
I think the ultimate goal is to figure out how to get iTest to 'Record and Replay' with minimal or no modifications to the recorded steps. We have used another java swing tool that can do the record and replay successfully so the bar has already been set.
My tester also found another issue with the frame number captured while executing a swing command:
//RedCellManagedObjectDefaultEdit[@name='frame18']/rootPane/layeredPane[@name='null.layeredPane']/panel[@name='null.contentPane']/panel/panel[2]/panel[1]/panel/button[@text='Apply' and @tooltip='Apply changes to this managed object']; left
My challenge to Fanfare is make this feature user friendly on the record and replay so iTest users don't have to manipulate recorded steps to rerun their test case. What can fanfare do to record the test so testers can focus on adding analysis rules and testing product? This is where I would like to go next.
As for now we are going to try handling this form the workflow as a workaround.
From a workflow perspective...I plan on having the testers close the swing client before recording a new test to reset the capture. I believe the "connect to existing session" will work for the test suite because the frames will match what was captured in iTest.
Thanks.
Thank you for your feedback. We have filed a feature request to improve this scenario in the future.
Another possible solution is that the developers can implement iTest's ITestable interface on the RedCellManagedObjectDefaultEdit class. Just add a few lines, and you can define a custom behavior for the target of the frame.
I would need more details regarding this option. Do you have some examples or documents explaining the ITestable interface.
Thanks.
Well ideally, if you are getting the developers involved, you would just ask them to give proper names to the frames rather than dynamic ones.
For ITestable, here is an example. The example deals with something different, i.e providing custom implementations to actions, but you'll get the gist of what Itestable can do. Note that you don't need to implement everything in ITestable, just the stuff that you'd like to override.
