The JFCUnit package comes with fairly crude yet usefull Swing component browser (junit.extensions.jfcunit.tools.ComponentBrowser). This tool allows you to browse the run-time hierarchy of components in a Swing application. This also includes convenient readout of various component properties at run-time.
However, I have run into a problem with this otherwise execelent tool. When it is launched as part of the application to be investigated the tool is inaccessible when the application opens a modal dialog.
One solution to this problem would of-course be to get rid of all modal dialogs but this is unfortunatly not an option. Therefore I seek answers to one or more of the following questions:
1) Is there a work-around for modal dialogs ?
2) Is there a way to launch the tool in a separate VM and attact it to the application in question ?
3) Since it is my impression that the answer to the two qeustions above is no: Can anybody recommend any open-source tools capable of running externally and attatch to a running application ?
Any general comments about the usefulness/limitations/pitfalls of such a tool are also welcome. I am quite new to the topic of GUI testing and have only been working with JFCUnit for a couple of weeks. I am, in fact, mainly trying to achieve GUI automation rather than actual testing. I want to be able to bring my GUI application repeatably into a certain state without having to perfom substantial error-prone user interaction.
Regards
Henrik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
first of all if your're looking for another testing framework checkout http://atomicobject.com/haste/info.page. It enables you to run tests in a different VM. Perhaps this could solve your problem. However, I have evaluated a list of open source testing frameworks, including haste, and eventually choose jfcunit. If I were you, I would stick to jfcunit. I think it's one of the best. It might be possible that the component browser can not be used when opening modal dialogs. Other tools don't even have a component browser. If you like, you could implement a component browser living in a different VM. You would need to use some interprocess communication like RMI or whatever protocol enabling you to transfer the component information from one VM to another. However, I'm not sure you really need the component browser. If all you need is to find out information about some component in your window, you can use the debugging feature of jfcunit. Start it with these commands:
This will log every swing event on your gui/modal dialog, including the component information of the component on which the event ran on. E.g. a mouseclick on a button will reveal the event "mouseclick", but also extra information about the button you clicked upon. (Perhaps it could be an interesting feature to log all child components too. Dig in the source and update the debugging tool... Of course you will post your updates to jfcunit to sourceforge, won't you)
Hope this helps.
Regards,
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also evaluated a few of the alternative GUI testing frameworks and concluded that jfcunit seemed to provide exactly what I needed (and usually seek in open source frameworks):
- functionality: basically just the handle to the event queue and the extendable component finder hierarchy
- maturity: the framework should have reached a certain level of maturity and stability.
- activety: the framework should used actively by others and have a resonable active and responsive forum
The reason that I want to use a component browser is that the application I am automating makes use of a third-party Swing component of which I know very little. Being able to browse the container and component structure would just appear to me to be a very convinient way identify the components (and their properties) I want to act on via automation.
I also want to be able to limit the search context for the component finder methods (identify subcontainers) since it seems that in some cases the components in the application are fairly anonymous (unnamed or with dynamically generated names that varies between each execution of the application). In essence, the application was not developed with this kind of automation in mind.
I will try your suggestion with the debug trace of the JFCEventManager (I wasn't aware of that approach at all - thanks!). That might be quite helpful, although I guess it provides limited information about the hierarchical structure. Maybe thats what you point out with your comment 'Perhaps it could be an interesting feature to log all child components too' ? I would think you meant 'parent' rather than 'child' in that case ? If I proceede to make a useful extension of the debugger in the form of an optional recording of the properties of parent containers (if it is not already possible) I will submit it back to the project.
Regards
Henrik
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for listing the arguments why one should use jfcunit... I'll use it to convince other people at work.
I'm using jfcunit to test a complete third-party Swing application. I'll add some of my experiences that might help you...
At start, I used the same approach as you: I started the third-party application from my main test method and ran, like you did, the component browser. Since this is a third-party application, I had no clue what kind of structure the GUI had. The component browser helped, but the structure of the GUI was very complex making it a time consuming job to browse all components of the GUI. So, I ended up with the debugging feature which helps me well. I basically need it, to find out what kind (read "which specific swing class") is visible. Most of the times this is obvious. Sometimes, it is not. Is it a JTable, a JList, a set of JButtons? Ones you know the swing class, you can use the component finder with this in your test to search for that component... E.g., if the component you need to find is a JTextField, use
new ComponentFinder(JTextField.class).findAll();
and you'll receive a list of all JTextFields available in the current JVM. After this, I "filter" out the exact textfield I need. An example: a. search for all JLabels, b. pick the JLabel with the text "username:". c. Now search for all JTextFields. d. Pick the JTextField with its possition as close as possible to the position of b. Now fill that textfield with the username of the test. Etc etc.
Another tip I would like to give is the following: The application I'm testing uses the jdk1.3. It uses classes that are not available in the the jdk1.4. I'm unable to use hot deployement features only available in the jdk1.4. I needed hot deployment because it's hard to re-run your complete script to test one final newly developed step in your script. So, run a test that sleeps at the end and polls a queue. This queue can be filled with classnames to run. Make a small gui to use to fill the queue with classes to run. When the "sleeper" receives a classname in the queue, it runs...
File file = new File("d:/my/directory/where/I/put/new/classes/to/test/");
URLClassLoader loader = new URLClassLoader(new URL[] { file.toURL() });
Class clazz = loader.loadClass(getClassName());
((SomeSortOfInterface) clazz.newInstance()).someMethod();
A new classloader is created with a directory different from any directory in your classpath (check out classloaders to find out why). Well, basically that's all I need.
regards,
Johan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The JFCUnit package comes with fairly crude yet usefull Swing component browser (junit.extensions.jfcunit.tools.ComponentBrowser). This tool allows you to browse the run-time hierarchy of components in a Swing application. This also includes convenient readout of various component properties at run-time.
However, I have run into a problem with this otherwise execelent tool. When it is launched as part of the application to be investigated the tool is inaccessible when the application opens a modal dialog.
One solution to this problem would of-course be to get rid of all modal dialogs but this is unfortunatly not an option. Therefore I seek answers to one or more of the following questions:
1) Is there a work-around for modal dialogs ?
2) Is there a way to launch the tool in a separate VM and attact it to the application in question ?
3) Since it is my impression that the answer to the two qeustions above is no: Can anybody recommend any open-source tools capable of running externally and attatch to a running application ?
Any general comments about the usefulness/limitations/pitfalls of such a tool are also welcome. I am quite new to the topic of GUI testing and have only been working with JFCUnit for a couple of weeks. I am, in fact, mainly trying to achieve GUI automation rather than actual testing. I want to be able to bring my GUI application repeatably into a certain state without having to perfom substantial error-prone user interaction.
Regards
Henrik
Hi,
first of all if your're looking for another testing framework checkout http://atomicobject.com/haste/info.page. It enables you to run tests in a different VM. Perhaps this could solve your problem. However, I have evaluated a list of open source testing frameworks, including haste, and eventually choose jfcunit. If I were you, I would stick to jfcunit. I think it's one of the best. It might be possible that the component browser can not be used when opening modal dialogs. Other tools don't even have a component browser. If you like, you could implement a component browser living in a different VM. You would need to use some interprocess communication like RMI or whatever protocol enabling you to transfer the component information from one VM to another. However, I'm not sure you really need the component browser. If all you need is to find out information about some component in your window, you can use the debugging feature of jfcunit. Start it with these commands:
JFCEventManager.setDebug(true);
JFCEventManager.setDebugType(JFCEventManager.DEBUG_OUTPUT);
JFCEventManager.setRecording(true);
This will log every swing event on your gui/modal dialog, including the component information of the component on which the event ran on. E.g. a mouseclick on a button will reveal the event "mouseclick", but also extra information about the button you clicked upon. (Perhaps it could be an interesting feature to log all child components too. Dig in the source and update the debugging tool... Of course you will post your updates to jfcunit to sourceforge, won't you)
Hope this helps.
Regards,
Johan
Hi Johan
Thanks for your comments.
I also evaluated a few of the alternative GUI testing frameworks and concluded that jfcunit seemed to provide exactly what I needed (and usually seek in open source frameworks):
- functionality: basically just the handle to the event queue and the extendable component finder hierarchy
- maturity: the framework should have reached a certain level of maturity and stability.
- activety: the framework should used actively by others and have a resonable active and responsive forum
The reason that I want to use a component browser is that the application I am automating makes use of a third-party Swing component of which I know very little. Being able to browse the container and component structure would just appear to me to be a very convinient way identify the components (and their properties) I want to act on via automation.
I also want to be able to limit the search context for the component finder methods (identify subcontainers) since it seems that in some cases the components in the application are fairly anonymous (unnamed or with dynamically generated names that varies between each execution of the application). In essence, the application was not developed with this kind of automation in mind.
I will try your suggestion with the debug trace of the JFCEventManager (I wasn't aware of that approach at all - thanks!). That might be quite helpful, although I guess it provides limited information about the hierarchical structure. Maybe thats what you point out with your comment 'Perhaps it could be an interesting feature to log all child components too' ? I would think you meant 'parent' rather than 'child' in that case ? If I proceede to make a useful extension of the debugger in the form of an optional recording of the properties of parent containers (if it is not already possible) I will submit it back to the project.
Regards
Henrik
Thanks for listing the arguments why one should use jfcunit... I'll use it to convince other people at work.
I'm using jfcunit to test a complete third-party Swing application. I'll add some of my experiences that might help you...
At start, I used the same approach as you: I started the third-party application from my main test method and ran, like you did, the component browser. Since this is a third-party application, I had no clue what kind of structure the GUI had. The component browser helped, but the structure of the GUI was very complex making it a time consuming job to browse all components of the GUI. So, I ended up with the debugging feature which helps me well. I basically need it, to find out what kind (read "which specific swing class") is visible. Most of the times this is obvious. Sometimes, it is not. Is it a JTable, a JList, a set of JButtons? Ones you know the swing class, you can use the component finder with this in your test to search for that component... E.g., if the component you need to find is a JTextField, use
new ComponentFinder(JTextField.class).findAll();
and you'll receive a list of all JTextFields available in the current JVM. After this, I "filter" out the exact textfield I need. An example: a. search for all JLabels, b. pick the JLabel with the text "username:". c. Now search for all JTextFields. d. Pick the JTextField with its possition as close as possible to the position of b. Now fill that textfield with the username of the test. Etc etc.
Another tip I would like to give is the following: The application I'm testing uses the jdk1.3. It uses classes that are not available in the the jdk1.4. I'm unable to use hot deployement features only available in the jdk1.4. I needed hot deployment because it's hard to re-run your complete script to test one final newly developed step in your script. So, run a test that sleeps at the end and polls a queue. This queue can be filled with classnames to run. Make a small gui to use to fill the queue with classes to run. When the "sleeper" receives a classname in the queue, it runs...
File file = new File("d:/my/directory/where/I/put/new/classes/to/test/");
URLClassLoader loader = new URLClassLoader(new URL[] { file.toURL() });
Class clazz = loader.loadClass(getClassName());
((SomeSortOfInterface) clazz.newInstance()).someMethod();
A new classloader is created with a directory different from any directory in your classpath (check out classloaders to find out why). Well, basically that's all I need.
regards,
Johan