jfcunit-devel — Development dicussion on the JFCUnit framework

[Jfcunit-devel] Component Finder

[<VRA...@th...>]

Here is the situation - in the next release of jfcunit we will have a
ComponentFinder class which has 2 attributes: class, value
The testComponent(Component) method looks something like this:
<code>
    public boolean testComponent(Component comp) {
        // do a search based on the compCls variable
        if(compCls == AbstractButton.class) {
            return(compCls.isInstance(comp)
                   && compareValues(String.class,
((AbstractButton)comp).getText(), value, true));
        } else if(compCls == JButton.class) {
            return(compCls.isInstance(comp)
                   && compareValues(String.class, ((JButton)comp).getText
(), value, true));
        } else if(compCls == JLabel.class) {
            return(compCls.isInstance(comp)
                   && compareValues(String.class, ((JLabel)comp).getText(),
value, true));
        } else if(compCls == JMenu.class) {
            // this is a "bug" since even though we do not set the name on
a JMenu,
            // the name is set to the text value automatically
            return(compCls.isInstance(comp)
                   && compareValues(String.class, ((JMenu)comp).getName(),
value, true));
        } else if(compCls == JMenuItem.class) {
            // this is a "bug" since even though we do not set the name on
a JMenuItem,
            // the name is set to the text value automatically
            return(compCls.isInstance(comp)
                   && compareValues(String.class, ((JMenuItem)comp).getName
(), value, true));
        } else if(compCls == JToggleButton.class) {
            return(compCls.isInstance(comp)
                   && compareValues(String.class,
((JToggleButton)comp).getName(), value, true));
        } else if(compCls == JToolBar.class) {
            // this is a "bug" since even though we do not set the name on
a JToolBar,
            // the name is set to the text value automatically
            return(compCls.isInstance(comp)
                   && compareValues(String.class, ((JToolBar)comp).getName
(), value, true));
        } else {
            // this case will be reached if either the compCls is null or
any of the
            // other 'if' conditions are not satisfied
            return((compCls == null || compCls.isInstance(comp))
                   && compareValues(String.class, comp.getName(), value,
true));
        }
    }
</code>

I am sure there is a better way of doing this - but am not sure how.
This is what a user wants: He creates a component (say JLabel) setting the
text property but not the name. Then he calls:
<code> findComponent(JLabel.class <someValue>, <theContainer>, <index>)
</code>

By default he can leave the "someValue" to be (String)null
and this works fine, but if he specifies it, what should he specify ?
comp.getText()? comp.getName()?
Because, for a JLabel we would intuitively use comp.getText() - while for
some other component (say JMenu) we would use comp.getName()

Is there any method in the JDK which would work for all javax.swing.*
components?
(I tried to use comp.getAccessibleContext().getAccessibleName() but that is
not available in JDK 1.2.2)

The end result should be that CompFinder should return the correct
component.

Please respond.
Thanks
Vijay

[Jfcunit-devel] JFCUnit and JDK 1.2.2!

[<rin...@me...>]

Hello JFCUnit developers,

First of all, thank you for correcting the 0.2.2 ZIP file on Sourceforge. I
downloaded it, but it seems that there is one method invocation that is 1.3
specific. Have a look at junit.extensions.jfcunit.tools.ComponentBrowser,
method componentSelected(Component). The first line reads:

propTableModel.setRowCount(0);

If you change it to 

propTableModel.seteNumRows(0);

you continue to be JDK 1.2 compatible.

My company uses VisualAge for Java for development, but this product only
has JDK 1.2.2 support, so I would like to ask you all to keep JDK 1.2
compatibility in mind.

Thanks in advance,

Ringo
---
Ringo De Smet                                          MediaGeniX NV
Access Forty - Gossetlaan 54         1702 Groot-Bijgaarden - Belgium
Phone: +32-(0)2-467.34.30                    Fax: +32-(0)2-467.34.39
mailto:Rin...@me...         http://www.mediagenix.com
---------------------------------------------------------------------
This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual(s) or entity to whom 
they are addressed.  If you have received this e-mail in error 
please notify the sender immediately.
---------------------------------------------------------------------

[Jfcunit-devel] Some Ideas

[Hans <hes...@sp...>]

Hello,

Congratulations for your work! It is a good idea to implement GUI-Tests i=
n=20
java and to use the facilities provided by the JUnit framework.

JFCUnit 0.2.1 pre-beta does not satisfy my needs completely. That's why I=
 had=20
a closer look at the code. And I think there are some design decisions th=
at=20
should be reconsidered:

1.) Listening for WINDOW_OPENED-WindowEvent
Since JDK 1.2 Frame.getFrames() can be used to get all open frames. I don=
't=20
think it is necessary to support older versions of the JDK anymore.

2.) Subclassing TestCase.
This makes it difficult to use the JFCUnit functionality outside JUnit or=
 by=20
other extensions of TestCase. I can't see any reason why this can't be do=
ne=20
by a separate class. The GUI-tests I do normally are integration tests. T=
his=20
means the test-driver starts the application then it performs serveral te=
st=20
and finally it closes down the application. This should be possible with=20
ordinary applications by executing their main-Method and with applets eve=
n=20
inside a browser.

3.) Providing Extension-Points.
It is difficult to extend JFCTestHelper without changing its implementati=
on.=20
For example I have to double-click on a list item. For that I need to acc=
ess=20
the private method fireMouseEventsOnComponent().

4.) Finding components with same search criteria.
It is not predictable which index belongs to which components. I would=20
suggest to return an array of components that is sorted by screen positio=
n.=20
This would be very useful to fill out a form with several text-fields.

5.) Combining different functionality in one method.
Methods like enterDropDownClick() or enterClickAndLeave() perform differe=
nt=20
actions: Locate a component and do something with a component. This cause=
s=20
you to provide N x N x ... x N Methods at the user interface instead of N=
 + N=20
+ ... N if you would split the functionality. Consider: How many methods=20
would you have to add if you added one other way to locate a component? A=
n=20
other disadvantage of combining functionality is that your methods have a=
 lot=20
of parameters and that there are many methods with the same name but=20
different signature. Even in this early release it is hard to learn the=20
inferface of JFCTestHelper. For more information on that you should have =
a=20
look at http://www.ambysoft.com/elementsJavaStyle.html and=20
http://www.ambysoft.com/javaCodingStandards.html.

6.) Generating KeyEvents with VK_UNDEFINED
I think it is dangerous to ignore the KeyCode in sendString() by replacin=
g it=20
with VK_UNDEFINED. As far as I know, VK_UNDEFINED is only allowed for "Ke=
y=20
typed" events (see javadoc).

To enhance the usefulness of JFCUnit I would suggest the following change=
s or=20
extensions:

1.) Provide a ComponentBrowser
This is not necessary to execute tests but to develop them. Currently I u=
se=20
dump-Methods to print the whole container hierarchy on System.out. But I=20
would prefer to place a new ComponentBrowser() inside my testcode that=20
started a GUI with a tree-view of all frames, windows and components on t=
he=20
left side and the properties of the selected component on the right side.

2.) Provide an AppletTestRunner
Applets behave differently if the are executed inside a browser. At least=
 for=20
integration it is necessary to automate such tests. There should be a=20
TestRunner that extends java.applet.Applet and can execute any JUnit-Test=
=2E

3.) Support Applet-Testing
There should be a helper class that can be used the same way as=20
junit.extensions.TestSetup to initialize and start an applet without usin=
g=20
AppletViewer. This is necessary to automate applet testing with Ant as pa=
rt=20
of an automated integration process.

4.) Move find-methods into a separate class.
This would make the interface of JFCUnit more concise and easier to use. =
The=20
find-methods should not be static. It should be possible to adjust the fi=
nd=20
strategy be properties of the finder class and to use several instances o=
f a=20
finder class with different strategies.

5.) Provide find-methods for trees, lists and tables.
Common tasks are editing table-cells, doubleclicking on list items and=20
selecting from the context menu of a tree node. Before such actions can b=
e=20
performed it is necessary to locate these items. I think most often it wi=
ll=20
do to locate the item by searching the model for a text-pattern specified=
 by=20
a regular expression. But it must be possible to search for specific Obje=
cts=20
(i. e. icons), too. In my opinion these specialized find methods should b=
e=20
separated by special classes.

6.) Provide polling-functionality for find-Methods.
With J2EE applications one never can say how long it will need until a=20
tree-node, list-item or component is shown. That's why the search must be=
=20
repeated until the item is visible or some time-out occurred.

7.) Abstract Event Generation
Currently there are two possibilities to generate AWT events: JFCTestHelp=
er=20
and java.awt.Robot. Both have advantages and disadvantages. A third=20
possiblity might be to write a DLL (using C++) to generate native window=20
events directly. It should be easy to switch between these possibilities.=
=20
This could be done by an interface that is implemented by a special JFC-R=
obot=20
class and by a subclass of java.awt.Robot.

8.) Compatibility
I think there are already many users of JFCUnit. To perform the suggested=
=20
changes without breaking their code I suggest not to change to interfaces=
 of=20
JFCTestCase and JFCTestHelper, but these classes should use the classes n=
oted=20
above.

9.) Examples
Examples are necessary to show how to use JFCUnit. I'd suggest to provide=
=20
test examples for sun's swing demos like SwingSet2 (JDK 1.3). This safes =
you=20
form implementing sample-GUIs.

This is just the result of a brain-storming. I hope the ideas are useful =
to=20
someone and nobody is mad about my criticism. Actually I would like to=20
contribute to JFCUnit, but I am absolutely new to open-source projects.

Thanks for reading this and sorry for my bad English. I would be glad to=20
receive your opinion about my ideas.

Best regards,

Hans J=F6rg Hessmann
hes...@sp...

RE: [Jfcunit-devel] Random ideas

[Matt C. <mat...@mo...>]

> -----Original Message-----
> From: Vijay Aravamudhan [mailto:vra...@th...]
> Sent: 04 October 2001 17:54
> To: mat...@mo...
> Subject: RE: [Jfcunit-devel] Random ideas
> 
> 
> This message was sent from Geocrawler.com by "Vijay 
> Aravamudhan" <vra...@th...>
> 
> Wouldnt all this be a moot point if we remove 
> RegisteringEventQueue and replace it with a 
> listener on the AWT Event queue?
> 
> (I might be repeating something that was already 
> said before - in fact I got the idea of the 
> listener from a previous post - but I am not sure 
> which is a better idea)
> Thanks
> Vijay
> 

Not sure what your point is here...please elaborate.

Using a listener on the AWT Event queue is a far better idea than using
RegisteringEventQueue (I wasn't aware of the technique when I wrote that
class). However that doesn't prevent us implementing some of the ideas
expressed in the post below.

BTW we should move our discussions on this sort of stuff to the
jfcunit-devel list (are you subscribed to it?)

Matt

> 
> ---------------------------------------
> Sorry for not replying earlier. I've been on 
> holiday!
> 
> Comments inserted below...
>  
> _____ 
> This email and any attachments are confidential 
> and are intended only for 
> the addressee. If you are not the intended 
> recipient of this email and have 
> received it in error, please notify the sender 
> immediately by reply email 
> and then delete it from your system. 
> 
> 
> > -----Original Message-----
> > From: C & C Helck 
> [mailto:pp0...@mi...]
> > Sent: 22 August 2001 04:06
> > To: jfc...@li...
> > Subject: [Jfcunit-devel] Random ideas
> > 
> > 
> > I've been looking at jfcunit and trying to put 
> it and its 
> > concepts into use 
> > over the last two months in my spare time. Here 
> are some ideas and 
> > comments. I hope they spark some dialog and 
> some better 
> > ideas. I don't have 
> > jfcunit in front of me so I'm going to play 
> fast and loose with names.
> > 
> > 1. Testing a GUI is hard. I don't think a 
> single subclass of 
> > TestCase will 
> > work for everyone. I suggest decomposing 
> jfcunit into a collection of 
> > reusable objects: a couple of different types 
> of TestCases 
> > and various 
> > Helper classes.
> > 
> > 2. The mechanism which starts and stops the AWT 
> event loop 
> > should be broken 
> > out into its own class. Its signature might 
> look like this:
> > 
> > class AwtPlug {
> > 	public void insertPlug(int n);  // 
> Removes itself after 
> > n milliseconds
> > 	public void insertPlug();
> > 	public void removePlug();
> > }
> >
> 
> Good idea. I like this.
>  
> > This could be useful to people who need to roll 
> their own TestCases.
> > 
> > 3. A bunch of Helpers for finding Components is 
> needed. I 
> > know this is 
> > being worked on.
> > 
> > 4. A separate Helper to track Windows and 
> Dialogs is needed. 
> > I'm suppose to 
> > be working on this.... I have one, but its not 
> ready for 
> > prime time yet. 
> > Anyway I'm struck with how awkward this is. It 
> would be nice 
> > if AWT or 
> > Swing could give me a list of all Windows and 
> Dialogs.
> > 
> > 5. A bunch of input helpers are needed. I think 
> they should 
> > be independent 
> > of the other Helpers and each other. Some 
> people want to use 
> > an awt.Robot 
> > approach, some people need to spoof events on 
> the EventQueue 
> > directly, and 
> > others will want to find use doClick() and the 
> like.
> > 
> 
> It would be nice to be able to "hot-switch" the 
> method that you are using to
> create events - e.g. we could use some form of 
> strategy pattern - the
> interface is the same we just change the 
> implementation. Don't know how that
> would work in terms of code!
> 
> > 6. jfcunit makes use of a pause method that's 
> called something like 
> > awtSleep(). Basically in a typical test you 
> create some 
> > components, trigger 
> > some input events, release the EventQueue for a 
> short time, 
> > and then check 
> > the components to see that they are in the 
> correct state. 
> > I've had a lot of 
> > problems with this because the tests are very 
> sensitive to 
> > the time that 
> > the EventQueue is running. If you use a long 
> time then your 
> > tests run slow. 
> > If you use to short a time then all the events 
> on the 
> > EventQueue may not be 
> > processed and your asserts will fail. Times 
> that are long 
> > enough on my 
> > machine, may not be long enough on a different 
> slower machine.
> > 
> > Techniques like waiting for the EventQueue to 
> be empty are 
> > error prone.
> > 
> > Would it be better to release the EventQueue 
> and repeatedly 
> > run the asserts 
> > until they all pass or a timeout occurs? If a 
> large timeout 
> > is used (say 10 
> > seconds) then the successful tests will run 
> quickly, and the 
> > failed tests 
> > will eventually timeout. I have no idea what 
> the code would 
> > look like yet. 
> > How about this:
> > 
> > 	public void testGui() {
> > 		createPanels();
> > 		clickOnAButton();
> > 		awtSleep();    // Release Event 
> Queue
> > 
> > 		assertTimed(new Repeater() {
> > 			public void run() {
> > 				assertNotNull( 
> > Helper.findText("Hello World!") ));
> > 			}
> > 		});
> > 	}
> > 
> 
> This will be ok as long as the things that you 
> are asserting do not have any
> side effects. Is it bad practice to assert things 
> that have side effects?
> Not sure. Maybe we could supply this as an option.
> 
> 
> > 7. How can we support different versions of the 
> JDK? Suppose we add a 
> > helper class that uses the awt.Robot. Would 
> this screw people who are 
> > running in 1.2.2 and earlier? How would the ant 
> scripts need 
> > to be modified 
> > to do this? Is this really a problem?
> > 
> 
> We could use a strategy pattern as described 
> above - you only use that
> strategies that work for your particular JDK 
> version.
> 
> 
> > 8. That's it for now.
> > 
> > Thanks,
> > Christopher Helck
> > 
> > 
> > _______________________________________________
> > Jfcunit-devel mailing list
> > Jfc...@li...
> > 
> http://lists.sourceforge.net/lists/listinfo/jfcuni
> t-devel
> > 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcuni
> t-devel
> 
> 		
> 
> Geocrawler.com - The Knowledge Archive
> 

[Jfcunit-devel] Java GUI automation.

[Bret P. <Bret_Patterson/<Tiv...@us...>]

I just ran across this project a few days ago and wanted to say hello. 
I've actually been working on a pure Java GUI Automation test framework 
for the past year. I'm in the process of open sourcing it as it's grown 
quite large(about 30,000 lines of code) and I think the industry could 
benefit alot from it.

I just wanted to answer some of the general questions I've seen while 
browsing the past messages and the boards as I've run across all those 
issues and spent alot of time solving them.

Listening to Events:

There are two methods to doing this, I actually use both methods since 
each has it's inherent problems and limitations.

1. Using the Toolkit.getDefaultToolkit().addAWTEventListener. This method 
is great and I believe someone already discussed this. The only weakness 
is you can't obtain swing specific events. IE TableModelEvents, 
ListSelection Events etc. 
2. Using the Sun Accessibility Utilities. This package actually was built 
specifically for this purpose. It allows you to register global listeners 
for all AWT Based events as well as all Swing based events. In addition it 
allows you to obtain a listing of all currently visible windows. 

#2 works great but I've run into a few bugs that were quite annoying and 
is why I use both. 


Working with Modal dialog boxes:

Modal dialog boxes are pain until you figure out how they work. Whenever 
you perform an action that opens a modal dialog box, IE push a button, the 
line of code that shows the modal dialog box blocks until the dialog box 
is hidden or destroyed,. The modal dialog appears to accomplish this by 
doing the following:
Blocking the current EventDispatch Thread.
Creating a new EventDispatch thread so that events can continue to be 
delivered, but in a controled manner (IE maintain this windows modality).

What this means is the line of code that created this dialog box will 
block causing your testcase to block until the Modal dialog disappears. 
This is a major problem as then you can't do what you need to do in the 
modal dialog. The technique for working around this is the following:
SwingUtilities.invokeLater(<your runnable here>);  // dispatch this action 
asynchronously, we'll worry about waiting for it to finish later.
SwingUtilities.invokeAndWait (<empty runnable>); // since the Event 
Dispatcher is essentially a FIFO queue this won't run until the previous 
operation has been handled

The first line of code performs the action you desired asynchronously 
because we can't afford to block in the case where we trigger a modal 
dialog. The second line of code ensure thats the Event Dispatcher thread 
has finished handling the previous action. In the case of a dialog box the 
first one run will actually have it's thread blocked in the background by 
the dialog box. However the Dialog box creates a new Dispatcher Thread in 
which it will run the second line as soon as it's ready to dispatch events 
again, which is as soon as the Dialog Windows comes up. Essentially we are 
dispatching an event and then waiting for the dispatch thread to become 
idle.

Also keep in mind that since Swing is not thread safe, any action you 
perform that could possibly trigger an event handler(s) has to be run 
within the Event Dispatcher thread. Essentially this means an action that 
triggers a state change of a control has to be done in that thread, hence 
the use of invokeLater and invokeAndWait.  I've noticed alot of commercial 
apps don't live by this rule in their code, and it causes alot of problems 
in GUI test harness that listen for events because in alot of cases they 
can have their event handlers run in seperate threads simultaneously 
causing all kinds of problems.


Anyway I'll be happy to answer questions anyone has if I can. I can't talk 
about my project too much until we get further along in the open source 
process.

Bret Patterson

RE: [Jfcunit-devel] Random ideas

[Matt C. <mat...@mo...>]

Sorry for not replying earlier. I've been on holiday!

Comments inserted below...
 
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: C & C Helck [mailto:pp0...@mi...]
> Sent: 22 August 2001 04:06
> To: jfc...@li...
> Subject: [Jfcunit-devel] Random ideas
> 
> 
> I've been looking at jfcunit and trying to put it and its 
> concepts into use 
> over the last two months in my spare time. Here are some ideas and 
> comments. I hope they spark some dialog and some better 
> ideas. I don't have 
> jfcunit in front of me so I'm going to play fast and loose with names.
> 
> 1. Testing a GUI is hard. I don't think a single subclass of 
> TestCase will 
> work for everyone. I suggest decomposing jfcunit into a collection of 
> reusable objects: a couple of different types of TestCases 
> and various 
> Helper classes.
> 
> 2. The mechanism which starts and stops the AWT event loop 
> should be broken 
> out into its own class. Its signature might look like this:
> 
> class AwtPlug {
> 	public void insertPlug(int n);  // Removes itself after 
> n milliseconds
> 	public void insertPlug();
> 	public void removePlug();
> }
>

Good idea. I like this.
 
> This could be useful to people who need to roll their own TestCases.
> 
> 3. A bunch of Helpers for finding Components is needed. I 
> know this is 
> being worked on.
> 
> 4. A separate Helper to track Windows and Dialogs is needed. 
> I'm suppose to 
> be working on this.... I have one, but its not ready for 
> prime time yet. 
> Anyway I'm struck with how awkward this is. It would be nice 
> if AWT or 
> Swing could give me a list of all Windows and Dialogs.
> 
> 5. A bunch of input helpers are needed. I think they should 
> be independent 
> of the other Helpers and each other. Some people want to use 
> an awt.Robot 
> approach, some people need to spoof events on the EventQueue 
> directly, and 
> others will want to find use doClick() and the like.
> 

It would be nice to be able to "hot-switch" the method that you are using to
create events - e.g. we could use some form of strategy pattern - the
interface is the same we just change the implementation. Don't know how that
would work in terms of code!

> 6. jfcunit makes use of a pause method that's called something like 
> awtSleep(). Basically in a typical test you create some 
> components, trigger 
> some input events, release the EventQueue for a short time, 
> and then check 
> the components to see that they are in the correct state. 
> I've had a lot of 
> problems with this because the tests are very sensitive to 
> the time that 
> the EventQueue is running. If you use a long time then your 
> tests run slow. 
> If you use to short a time then all the events on the 
> EventQueue may not be 
> processed and your asserts will fail. Times that are long 
> enough on my 
> machine, may not be long enough on a different slower machine.
> 
> Techniques like waiting for the EventQueue to be empty are 
> error prone.
> 
> Would it be better to release the EventQueue and repeatedly 
> run the asserts 
> until they all pass or a timeout occurs? If a large timeout 
> is used (say 10 
> seconds) then the successful tests will run quickly, and the 
> failed tests 
> will eventually timeout. I have no idea what the code would 
> look like yet. 
> How about this:
> 
> 	public void testGui() {
> 		createPanels();
> 		clickOnAButton();
> 		awtSleep();    // Release Event Queue
> 
> 		assertTimed(new Repeater() {
> 			public void run() {
> 				assertNotNull( 
> Helper.findText("Hello World!") ));
> 			}
> 		});
> 	}
> 

This will be ok as long as the things that you are asserting do not have any
side effects. Is it bad practice to assert things that have side effects?
Not sure. Maybe we could supply this as an option.


> 7. How can we support different versions of the JDK? Suppose we add a 
> helper class that uses the awt.Robot. Would this screw people who are 
> running in 1.2.2 and earlier? How would the ant scripts need 
> to be modified 
> to do this? Is this really a problem?
> 

We could use a strategy pattern as described above - you only use that
strategies that work for your particular JDK version.


> 8. That's it for now.
> 
> Thanks,
> Christopher Helck
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> 

[Jfcunit-devel] Random ideas

[C & C H. <pp0...@mi...>]

I've been looking at jfcunit and trying to put it and its concepts into use 
over the last two months in my spare time. Here are some ideas and 
comments. I hope they spark some dialog and some better ideas. I don't have 
jfcunit in front of me so I'm going to play fast and loose with names.

1. Testing a GUI is hard. I don't think a single subclass of TestCase will 
work for everyone. I suggest decomposing jfcunit into a collection of 
reusable objects: a couple of different types of TestCases and various 
Helper classes.

2. The mechanism which starts and stops the AWT event loop should be broken 
out into its own class. Its signature might look like this:

class AwtPlug {
	public void insertPlug(int n);  // Removes itself after n milliseconds
	public void insertPlug();
	public void removePlug();
}

This could be useful to people who need to roll their own TestCases.

3. A bunch of Helpers for finding Components is needed. I know this is 
being worked on.

4. A separate Helper to track Windows and Dialogs is needed. I'm suppose to 
be working on this.... I have one, but its not ready for prime time yet. 
Anyway I'm struck with how awkward this is. It would be nice if AWT or 
Swing could give me a list of all Windows and Dialogs.

5. A bunch of input helpers are needed. I think they should be independent 
of the other Helpers and each other. Some people want to use an awt.Robot 
approach, some people need to spoof events on the EventQueue directly, and 
others will want to find use doClick() and the like.

6. jfcunit makes use of a pause method that's called something like 
awtSleep(). Basically in a typical test you create some components, trigger 
some input events, release the EventQueue for a short time, and then check 
the components to see that they are in the correct state. I've had a lot of 
problems with this because the tests are very sensitive to the time that 
the EventQueue is running. If you use a long time then your tests run slow. 
If you use to short a time then all the events on the EventQueue may not be 
processed and your asserts will fail. Times that are long enough on my 
machine, may not be long enough on a different slower machine.

Techniques like waiting for the EventQueue to be empty are error prone.

Would it be better to release the EventQueue and repeatedly run the asserts 
until they all pass or a timeout occurs? If a large timeout is used (say 10 
seconds) then the successful tests will run quickly, and the failed tests 
will eventually timeout. I have no idea what the code would look like yet. 
How about this:

	public void testGui() {
		createPanels();
		clickOnAButton();
		awtSleep();    // Release Event Queue

		assertTimed(new Repeater() {
			public void run() {
				assertNotNull( Helper.findText("Hello World!") ));
			}
		});
	}

7. How can we support different versions of the JDK? Suppose we add a 
helper class that uses the awt.Robot. Would this screw people who are 
running in 1.2.2 and earlier? How would the ant scripts need to be modified 
to do this? Is this really a problem?

8. That's it for now.

Thanks,
Christopher Helck

RE: [Jfcunit-devel] JTextFields and Key events

[Matt C. <mat...@mo...>]

I am interested in your code!

Things have been very quiet on the project recently - primarily due to the
fact that my work has been completely manic for about the last month.
However I have a few other patches to integrate and continue to accept
patches - I'm just not making any promises about when it'll make it into the
codebase!

Many thanks for your interest in JFCUnit

Matt

 
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: Dave Smith [mailto:dav...@ca...]
> Sent: 30 July 2001 21:07
> To: jfc...@li...
> Subject: [Jfcunit-devel] JTextFields and Key events
> 
> 
> I have hacked together some code that allows me to send key events to 
> TextFields. Is there someone else working on this or is someone 
> interested in this code?
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> 

[Jfcunit-devel] JTextFields and Key events

[Dave S. <dav...@ca...>]

I have hacked together some code that allows me to send key events to 
TextFields. Is there someone else working on this or is someone 
interested in this code?

[Jfcunit-devel] RE: jfcunit

[Matt C. <mat...@mo...>]

Thanks for the feedback. Let me know how you get on with the framework and
any features you'd like to see in the future.
 
Matt
(an Englishman in England!)
 



_____
This email and any attachments are confidential and are intended only for
the addressee. If you are not the intended recipient of this email and have
received it in error, please notify the sender immediately by reply email
and then delete it from your system.


-----Original Message-----
From: Malcolm Sparks [mailto:ms...@ei...]
Sent: 16 July 2001 18:00
To: m.c...@hu...
Subject: jfcunit


Matt, great idea, and well executed. 
 
I'm using jfcunit in anger in my test suite- 
That old excuse: "but I'm writing a gui, how
can I write unit tests?", now no longer applies.
Keep up the good work!
 
Malcolm
(an englishman in dublin)
 
PS: don't worry, if I run 
into any problems I'll go through the official list... ;-) 

[Jfcunit-devel] RE: Additions to JFCTestHelper - postEvent

[Matt C. <mat...@mo...>]

Many thanks for your patch - your input is greatly appreciated.

Currently you may or may not have noticed that JFCUnit doesn't have any
tests itself! This is because JFCUnit started life as some classes I knocked
together to help me test a project I was working on - it was not an
independent project in itself. Now though it is a high priority task for me
to go back and write test code for the framework. As a consequence patches
that are submitted without accompanying test code may not be integrated
particularly quickly.

If you are interested in assisting on the project I am actively recruiting
developers. Unfortunately the amount of time I can dedicate to the project
is very limited (particularly at the moment due to work pressures - this is
an "out of hours" project for me). If you'd be interested in helping out
then let me know.

The other thing that you ought to know is that it is our intention to
refactor the JFCTestHelper class and split it up into smaller classes - as
the design currently stands JFCTestHelper is just a big bucket of methods
that is going to grow indefinately as we add support for more components.
We'd like to have a helper class for each different type of component.
 
I would very happily take you up on your offer of lunch and a beer -
unfortunately I am based in the UK and am unlikely to visit Sunnyvale, CA in
the near future!

Keep me posted on your experience with JFCUnit and many thanks for your
support of the project.

Matt

 

This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: David Rudder [mailto:dr...@ar...]
> Sent: 12 July 2001 23:39
> To: ma...@us...
> Subject: Additions to JFCTestHelper - postEvent
> 
> 
> Mr. Caswell,
>     Hello!  I'm Dave Rudder, a coder with ArcSight, Inc.  We're using
> your excellent JFCUnit extension with excellent success.  It's missing
> a few features, which I'm currently trying to fix.
> 
>     Attached is the new JFCTestHelper.java. It has one extra function,
> postEvent, which allows us to send arbitrary events (for instance, a
> double-click or a window close).  
> 
> 
>     If it's alright with you, we'll continue to add whatever
> functionality we need and email you changes.  I also know how to use
> CVS and would be open to providing diffs if it would help.
> 
>     If you're in the Sunnyvale, CA area, I would enjoy the opportunity
> to take you out to lunch or maybe buy you a beer.
> 
> -Dave Rudder
> dr...@ar...
> 
> 
>  
> 

RE: [Jfcunit-devel] Some questions

[Matt C. <mat...@mo...>]

Ok. You are added as a developer to the project. Don't worry I'm pressed for
time too (especially just recently!) - any help is appreciated. 

Check out the "main" CVS module (ignore the other modules - they are dead
and need to be cleaned up at some point). Source files are within the "src"
sub-directory, and tests are in the "test" sub-directory. At the moment we
are very light on tests (this code was originally written as part of some
test code for an application I am working on and has only recently started
life in its own right). I have a task assigned to me to write some unit
tests but any help you can lend with filling in the blanks with the code
that you write would be appreciated. Tests should appear in the same package
(different directory) as the code that you are testing.

Matt
 
Matt Caswell 
Java Team Leader, Morse Professional Services 
Tel: +44 (0)1332 826116 Fax: +44 (0)1332 826044
Mobile: 07887 620205 
<http://www.morse.com/> www.morse.com 
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: C & C Helck [mailto:pp0...@mi...]
> Sent: 09 July 2001 03:02
> To: Matt Caswell
> Subject: RE: [Jfcunit-devel] Some questions
> 
> 
> My source forge user name is chelck.
> 
> I'll do my best, but I'm pressed for tiime - arn't we all?
> How do you want unit tests set up?
> 
> -Chris Helck
> 
> 
> >This sounds like a *much* better way of doing things. We 
> should change the
> >code!
> >
> >I'd be very happy for you to have a try at this. If you set 
> yourself up as a
> >user on Sourceforge and let me know your username I can add you as a
> >developer to the project.
> _____________________________________________________________________
> This message has been checked for all known viruses by the 
> MessageLabs Virus Scanning Service. For further information visit
> http://www.messagelabs.com/stats.asp
> 
> 

[Jfcunit-devel] RE: javadoc

[Matt C. <mat...@mo...>]

Thanks for the code. When I get an opportunity I'll add it to the project,
ready for the next release.

Would you be interested in being added as a developer to the project?

Matt

 
 
Matt Caswell 
Java Team Leader, Morse Professional Services 
Tel: +44 (0)1332 826116 Fax: +44 (0)1332 826044
Mobile: 07887 620205 
<http://www.morse.com/> www.morse.com 
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: German Morales [mailto:ger...@de...]
> Sent: 05 July 2001 16:33
> To: m.c...@hu...
> Subject: javadoc
> 
> 
> Hi,
> 
> I was trying to use your tool, and I found myself stuck 
> because there's few documentation.
> 
> Is often useful to see the api using the javadoc generated 
> documentation.
> 
> So, better than putting it as a Feature Request, I decided 
> to change the build.xml file to generate the api 
> documentation.
> 
> Here is the modified build.xml:
> 
> <?xml version="1.0" ?>
> <!-- Ant build file for the JFCUnit test framework -->
> <!-- Matt Caswell, 15 June 2001 -->
> 
> <project name="JFCUnit" default="test" basedir=".">
> <!--  <property name="build.compiler" value="javac" /> -->
>   <property name="src.dir" value="src" />
>   <property name="build.dir" value="build" />
>   <property name="test.dir" value="test" />
>   <property name="docs.dir" value="docs" />
>   <property name="docs.api.dir" value="docs/api" />
>   <property name="testcases.dir" 
> value="${test.dir}/junit/extensions/jfcunit" />
> 
>   <path id="classpath">
>     <pathelement path="${classpath}" />
>     <pathelement location="${src.dir}" />
>     <pathelement location="${test.dir}" />
>     <pathelement location="${build.dir}/jar" />
>   </path>
> 
>   <target name="prepare">
>     <tstamp />
>   </target>
> 
>   <target name="compile" depends="prepare">
>     <mkdir dir="${build.dir}" />
>     <mkdir dir="${build.dir}/jar" />
>     <javac srcdir="${src.dir}" destdir="${build.dir}/jar" >
>       <classpath refid="classpath" />
>     </javac>
>     <javac srcdir="${test.dir}" >
>       <classpath refid="classpath" />
>     </javac>
>   </target>
> 
>   <target name="clean" depends="prepare">
>     <delete dir="${build.dir}" />
>     <delete dir="${docs.api.dir}" />
>   </target>
> 
>   <target name="test" depends="compile">
>     <junit printsummary="yes" haltonfailure="yes">
>       <classpath refid="classpath" />
>       <batchtest>
>         <fileset dir="${testcases.dir}">
>           <include name="${testsuite}/*T.java" />
>         </fileset>
>       </batchtest>
>     </junit>
>   </target>
> 
>   <target name="package" depends="clean,test">
>     <mkdir dir="${build.dir}/zip" />
>     <mkdir dir="${build.dir}/zip/jfcunit" />
>     <mkdir dir="${build.dir}/zip/jfcunit/docs" />
>     <jar jarfile="${build.dir}/zip/jfcunit/jfcunit.jar" 
> basedir="${build.dir}/jar" />
>     <jar jarfile="${build.dir}/zip/jfcunit/src.jar" 
> basedir="${src.dir}" />
>     <jar jarfile="${build.dir}/zip/jfcunit/test.jar" 
> basedir="${test.dir}"
>          excludes="**/*.class" />
>     <copy todir="${build.dir}/zip/jfcunit/docs">
>       <fileset dir="${docs.dir}" />
>     </copy>
>     <copy file="build.xml" 
> tofile="${build.dir}/zip/jfcunit/build.xml" />
>     <copy file="LICENSE" 
> tofile="${build.dir}/zip/jfcunit/LICENSE" />
>     <copy file="README" 
> tofile="${build.dir}/zip/jfcunit/README" />
>     <zip zipfile="${build.dir}/jfcunit.zip" 
> basedir="${build.dir}/zip" />
>   </target>
> 
>   <target name="docapi">
>     <mkdir dir="${docs.api.dir}"/>
>     <javadoc
>         packagenames="junit.extensions.jfcunit"
>         sourcepath="${src.dir}"
>         destdir="${docs.api.dir}"
>         >
>     </javadoc>
>   </target>
> </project>
> 
> The only thing left is to hang the docapi target to some 
> other.
> 
> I hope this help other users.
> 
> Bye!
> 
> German Morales.
> 

RE: [Jfcunit-devel] Some questions

[Matt C. <mat...@mo...>]

My view is "more b than a" - but ultimately both.


Matt
 
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: German Morales [mailto:ger...@de...]
> Sent: 05 July 2001 21:38
> To: jfc...@li...
> Subject: RE: [Jfcunit-devel] Some questions
> 
> 

> Based on this discussion I would like to get a clear idea of the 
> intented use of this framework.
> 
> a. Is it for people writing components, or may be implementing a 
> new look and feel, or in general, writing some swing extension? In 
> this case they look like Unit Tests.
> 
> b. Is it for people writing applications who want test how it works? 
> This seem to me like Functional Tests.
> 
> a --> In this case it seems ok to start an example application from 
> scratch for each test.
> 
> b --> On the other hand, this case needs another aproach. For example,
> if you want to test some dialog that appears after a login sequence 
> and some user interaction, you should include some way to start the 
> tests *inside* the application.
> 
> I will also point that what I would welcome are both a and b, because 
> we are writing an application which needs a not standard look and 
> feel.
> 
> Regards,
> 
> German Morales
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> 

RE: [Jfcunit-devel] Some questions

[German M. <ger...@de...>]

>> > > 4) Any ideas about how to setup and teardown tests that
>> > > involve a main
>> > > application?  Is there a way to end and restart the GUI thread?
>> > >
>> >
>> >Not sure what you mean by "involving a main application" - 
>> can you give an
>> >example?
>> 
>> I'm asking how do I write multiple tests on an application? 
>> Suppose you 
>> want to test login sequences. You need a test for a good 
>> login, a login 
>> with a bad user name, a login with a bad password, and so 
>> forth and so on. 
>> How do you write setUp() and tearDown() methods so that each 
>> test starts 
>> with a clean slate?
>> 
>
>As Greg has said we are looking at ways to stop and restart the 
AWT Thread.
>Greg has some sample code that he is working with.
>
>Matt

Based on this discussion I would like to get a clear idea of the 
intented use of this framework.

a. Is it for people writing components, or may be implementing a 
new look and feel, or in general, writing some swing extension? In 
this case they look like Unit Tests.

b. Is it for people writing applications who want test how it works? 
This seem to me like Functional Tests.

a --> In this case it seems ok to start an example application from 
scratch for each test.

b --> On the other hand, this case needs another aproach. For example,
if you want to test some dialog that appears after a login sequence 
and some user interaction, you should include some way to start the 
tests *inside* the application.

I will also point that what I would welcome are both a and b, because 
we are writing an application which needs a not standard look and 
feel.

Regards,

German Morales

RE: [Jfcunit-devel] Some questions

[Matt C. <mat...@mo...>]

Comments inserted...
_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: Catharine Helck [mailto:cr...@mi...]
> Sent: 05 July 2001 04:36
> To: jfc...@li...
> Subject: RE: [Jfcunit-devel] Some questions
> 
> 
> At 04:28 PM 7/4/01 +0100, Matt Caswell wrote:
> 
> > > 1) Why subclass and push your own event queue? Could you
> > > track the opening
> > > and closing of windows through an AWTEventListener 
> instead? I have an
> > > application which uses its own event queue and can't coexist
> > > with JFCUnit.
> > >
> >
> >A listener can only listen on a component that you have a 
> handle on. If you
> >don't have a handle on a component you can't put a listener 
> on it. The
> >custom event queue enables us to listen for open window 
> events for windows
> >that we have no handle on. We could maybe make some changes 
> to enable us to
> >optionally switch this facility off - the result of this 
> being that you
> >would have to get hold of window handles some other way.
> 
> AWTEventListeners are attached to the event queue and not a 
> component. They 
> are notified whenever an event type that they are interested 
> in goes across 
> the queue. This includes window open/close events. See the 
> following code:
> 
> import java.awt.*;
> import java.awt.event.*;
> import javax.swing.*;
> import java.util.*;
> 
> public class Test {
> 
>      public static void main(String argv[]) {
>          AWTEventListener l = new AWTEventListener() {
>              public void eventDispatched(AWTEvent e) {
>                  System.out.println("AWTEvent " + e);
>              }
>          };
> 
>          Toolkit.getDefaultToolkit().addAWTEventListener(l, 
> AWTEvent.WINDOW_EVENT_MASK);
> 
> 
>          JFrame frame = new JFrame();
>          frame.setVisible(true);
>          JOptionPane.showMessageDialog(null, "Hi", "Hi", 
> JOptionPane.ERROR_MESSAGE);
>      }
> }
> 
> Here's the output I got:
> 
> AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on frame0
> AWTEvent java.awt.event.WindowEvent[WINDOW_OPENED] on frame0
> AWTEvent java.awt.event.WindowEvent[WINDOW_DEACTIVATED] on frame0
> AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on dialog0
> AWTEvent java.awt.event.WindowEvent[WINDOW_OPENED] on dialog0
> AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on frame0
> AWTEvent java.awt.event.WindowEvent[WINDOW_CLOSED] on dialog0
> AWTEvent java.awt.event.WindowEvent[WINDOW_CLOSING] on frame0
> AWTEvent java.awt.event.WindowEvent[WINDOW_DEACTIVATED] on frame0
> 
> I'd think you could create a listener to keep track of the 
> windows and 
> dialogs as they are opened and closed.
> If you'd like I'd be happy to give this a try.
> 
> BTW: I haven't looked at Java 1.4 very closely yet, but I 
> think they now 
> have a way to get a set of open windows. So this whole issue 
> may become moot.
> 

The reason it wasn't done like this was that I wasn't aware of the
technique!!! ;-)

This sounds like a *much* better way of doing things. We should change the
code!

I'd be very happy for you to have a try at this. If you set yourself up as a
user on Sourceforge and let me know your username I can add you as a
developer to the project.


> [snip]
> 
> > > 4) Any ideas about how to setup and teardown tests that
> > > involve a main
> > > application?  Is there a way to end and restart the GUI thread?
> > >
> >
> >Not sure what you mean by "involving a main application" - 
> can you give an
> >example?
> 
> I'm asking how do I write multiple tests on an application? 
> Suppose you 
> want to test login sequences. You need a test for a good 
> login, a login 
> with a bad user name, a login with a bad password, and so 
> forth and so on. 
> How do you write setUp() and tearDown() methods so that each 
> test starts 
> with a clean slate?
> 

As Greg has said we are looking at ways to stop and restart the AWT Thread.
Greg has some sample code that he is working with.

Matt



> Thanks,
> Christopher Helck
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> 

Re: [Jfcunit-devel] Refactoring JFCTestHelper

[German M. <ger...@de...>]

>> 1. ComponentHelper.findComponent() throws JFCUnitTargetNotFound.
It might 
>> be easier to use if it returned null instead of throwing. Suppose 
you want 
>> to test that a component has been removed from the Component hierarchy,
how 
>> would you write the test?
>> 
>>          void testEasy() {
>>                  assertNull( ComponentHelper.findComponent(...));
>>          }
>> 
>>          void testHard() {
>>                  try {
>>                          ComponentHelper.findComponent(...);
>>                  }
>>                  catch (JFCUnitTargetNotFound()) {
>>                          return;
>>                  }
>>                  fail();
>>          }
>> 
>> No doubt there's an easier way to write the 2nd test, but I think 
I've made 
>> my point.
>> 
>
>Agreed, null would be easier.

Sorry, but I don't think this is a good idea.

My opinion is that you look for components in order to use them later 
in your test. The example given above just check if the component 
exists.
What happens if you get a null instead of the component you were 
looking for?

void testEasy() {
    Component comp = ComponentHelper.findComponent(...);

    // NullPointerException
    comp.someMethod();

    // Another posible NullPointerException (bug just submitted)
    JFCTestHelper.enterClickAndLeave(this, comp);
}

void testHard() {
    Component comp = ComponentHelper.findComponent(...);

    // To avoid errors...?
    if (comp != null) {
        comp.someMethod();

        // Another posible NullPointerException (bug just submitted)
        JFCTestHelper.enterClickAndLeave(this, comp);
    }
}

The test methods are allowed to throw exceptions, and I think this 
is the best way to solve this problem:

void testEasy() throws JFCUnitTargetNotFound {
    Component comp = ComponentHelper.findComponent(...);

    // not null if reached this point

    comp.someMethod();

    JFCTestHelper.enterClickAndLeave(this, comp);
}

Re: [Jfcunit-devel] Refactoring JFCTestHelper

[Greg H. <gho...@ya...>]

Comments inline.   Thanks for the review, this really helps!


--- C & C Helck <pp0...@mi...> wrote:
> Comments inline.
> 
> At 06:06 AM 7/3/01 -0700, Greg Houston wrote:
> 
> >Mr Helck,
> >
> >Thanks for reviewing the code.  Matt and I will have to discuss yor 
> >questions to see if we should
> >make some design changes.  We are currently make some changes to 
> >JFCTestHelper.  I would really
> >like you to comment on the design.  Could you take a look at
> >http://www.geocrawler.com/archives/3/13039/2001/6/0/6048488/  and tell us 
> >what you think?
> 
> I happy to review things. I'll start with specific issues and end with more 
> general ones.
> 
> 1. ComponentHelper.findComponent() throws JFCUnitTargetNotFound. It might 
> be easier to use if it returned null instead of throwing. Suppose you want 
> to test that a component has been removed from the Component hierarchy, how 
> would you write the test?
> 
>          void testEasy() {
>                  assertNull( ComponentHelper.findComponent(...));
>          }
> 
>          void testHard() {
>                  try {
>                          ComponentHelper.findComponent(...);
>                  }
>                  catch (JFCUnitTargetNotFound()) {
>                          return;
>                  }
>                  fail();
>          }
> 
> No doubt there's an easier way to write the 2nd test, but I think I've made 
> my point.
> 

Agreed, null would be easier.


> 2. I don't understand how ComponentHelper is related to ButtonHelper. Does 
> ButtonHelper extend ComponentHelper? I ask this because they look as if 
> there should be a common interface.
> 

The idea was ButtonHelper would have extra methods for manipulating and inspecting buttons. 
ComponentHelper and ButtonHelper would probably implement the same interfaces, but Button helper
would add some more methods.  It looks like these class need to be spec'd out more.


> 3. ComponentFinder.testComponent() and various findComponent() methods. 
> This is a style issue, but I would not pass an arg Object down to the 
> ComponentFinder from the findComponent method. Instead I would expect the 
> various instances of ComponentFinder to include whatever arguments they 
> need to decide if they want the given component.  I see this is a change 
> from the beta release. Why the change?
> 

The JFCTestHelper design worked ok when the testComponent method was defined as an inner class. 
This means parameters that control the search have to be 'final' so the inner class can access it.
 Instead, I wanted to make it possible to define testComponent() methods that were contained in
inner classes.  So, how do you send extra arguments to the testComponent() method?  That is why I
added the Object arg parameter.  This allows the caller to send some argument to testComponent to
control how testComponent works.

In the future, we may create a library of testComponent() routines that people can use to find the
component they want.  For now, I think finding a component by name is a good start.




> 4. RegisteringEventQueue. Have it return a Set or List of windows instead 
> of an Iterator. The Collection is more useful and just as safe as the 
> Iterator since you've cloned it. In the original code 
> TestHelper.getWindows() turns the Iterator back into a Set. Ugh.
> 

Sounds good to me.


> 5. Various findComponent() methods. The index argument doesn't seem very 
> useful. In the original code the index is used to get the nth entry in the 
> Component array returned by Container.getComponents(). It's my 
> understanding that the ordering of this array is arbitrary -- most likely 
> representing the order in which the components we added, but maybe not. 
> Perhaps findComponent() should return a Collection of Components which the 
> user could sort in different ways. Maybe the most useful way would be in 
> screen order (top to bottom, left to right), but other ways are possible too.
> 

The new design eliminates the index argument.  If someone wants to find the n'th component they
could pass n in the Object arg parameter to testComponent().



> 6. Does SwingUtilities.windowForComponent() do what 
> ComponentHelper.getWindow() already does?
> 
> 7. The various Helper classes seem to be doing two different things: they 
> help find Components and Windows, and they help manipulate the Components. 
> This functionality should be split into distinct classes. I would avoid 
> helper routines like getLabel() because Components like JLabel already have 
> easy ways to get this.
> 

Yes, I am rethinking the idea of having multiple instances of Helper methods each with a Target. 
The other option is to have a single instance, and the user passes the target to the Helper as a
parameter to each call.  The Helper methods could be either static (class methods), or the Helper
could be a singleton.  IIf Helper uses static methods, then there could be problems with the
methods getting Shadowed instead of Overloaded by sub-classes.

Any thoughts?



> 8. How about breaking the Helper up along functional lines?
> 
>          Classes/methods to get the set of Windows.
>          Classes/methods to get the set of Components in a Window or 
> Contrainer.
>          Classes/methods to filter a set of Components.
>          Classes/methods to generate mouse and keyboard events.
>          Classes/methods to manipulate Components.
> 
> Examples of filters are anything that uses a ComponentFinder. It just works 
> on a set instead of a tree. Another filter would be one that given a set of 
> Components returns the subset of enabled components.
> 
> Examples of manipulators are enterClickLeave().
> 

In addition, there need to be Classes/methods to inspect the components.  Can you give us an
interface definition for what you are thinking?

> 9. What's the motivation for refactoring TestHelper? What problems are you 
> trying to solve? What aspects of it do you like that you want to preserve?
> 
> 

JFCTestHelper is becomming a really large class.  Imagine how large it would be if it had methods
for to find, manipliate, and inspect every Swing component.  Many smaller classes will make it
easy to find the methods that support a particular component.

> >Are you interested in contributing to JFCUnit?
> 
> Yes.
> 

Thanks!  We can use the help.


> PS. I'm writing this from home on my wife's machine. That's why the return 
> address is sometimes to me and sometimes to my wife. It doesn't matter.
> 
> -Christopher Helck
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

RE: [Jfcunit-devel] Some questions

[Joi E. <jo...@ar...>]

On Wed, 4 Jul 2001, Catharine Helck wrote:

> BTW: I haven't looked at Java 1.4 very closely yet, but I think they now 
> have a way to get a set of open windows. So this whole issue may become moot.
> 

One of the peanut gallery pipes up.  "If you write JFCUnit to require
Java 1.4 for functionality, I won't be able to use it.  1.4 is not
yet available for all platforms my application must run on, and I will
not be able to run unit test verification on all my platforms.
which means I will not be able to even start using JFCUnit until
all my platforms have JDK 1.4."

Heck.  One of my platforms doesn't have a non-beta 1.3.0 yet!

While it makes your life as implementors a bit more difficult, please
consider keeping the JFCUnit codebase at a 1.2.2 or 1.3.0 level.  This
will gain you a much wider potential audience.

(Obviously you have to keep JFCUnit compatible with 1.4 like JUnit
had to deprecate its own assert() method...  But please don't use
java.awt.robot or classes new to 1.3.0 or 1.4 because I can't use it,
then.)

-- 
Joi Ellis                    Software Engineer
Aravox Technologies          jo...@ar..., gy...@vi...

No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried.  Anything
that kicks a monopoly in the pants has got to be good for something.
           - Chris Johnson

Re: [Jfcunit-devel] Refactoring JFCTestHelper

[C & C H. <pp0...@mi...>]

Comments inline.

At 06:06 AM 7/3/01 -0700, Greg Houston wrote:

>Mr Helck,
>
>Thanks for reviewing the code.  Matt and I will have to discuss yor 
>questions to see if we should
>make some design changes.  We are currently make some changes to 
>JFCTestHelper.  I would really
>like you to comment on the design.  Could you take a look at
>http://www.geocrawler.com/archives/3/13039/2001/6/0/6048488/  and tell us 
>what you think?

I happy to review things. I'll start with specific issues and end with more 
general ones.

1. ComponentHelper.findComponent() throws JFCUnitTargetNotFound. It might 
be easier to use if it returned null instead of throwing. Suppose you want 
to test that a component has been removed from the Component hierarchy, how 
would you write the test?

         void testEasy() {
                 assertNull( ComponentHelper.findComponent(...));
         }

         void testHard() {
                 try {
                         ComponentHelper.findComponent(...);
                 }
                 catch (JFCUnitTargetNotFound()) {
                         return;
                 }
                 fail();
         }

No doubt there's an easier way to write the 2nd test, but I think I've made 
my point.

2. I don't understand how ComponentHelper is related to ButtonHelper. Does 
ButtonHelper extend ComponentHelper? I ask this because they look as if 
there should be a common interface.

3. ComponentFinder.testComponent() and various findComponent() methods. 
This is a style issue, but I would not pass an arg Object down to the 
ComponentFinder from the findComponent method. Instead I would expect the 
various instances of ComponentFinder to include whatever arguments they 
need to decide if they want the given component.  I see this is a change 
from the beta release. Why the change?

4. RegisteringEventQueue. Have it return a Set or List of windows instead 
of an Iterator. The Collection is more useful and just as safe as the 
Iterator since you've cloned it. In the original code 
TestHelper.getWindows() turns the Iterator back into a Set. Ugh.

5. Various findComponent() methods. The index argument doesn't seem very 
useful. In the original code the index is used to get the nth entry in the 
Component array returned by Container.getComponents(). It's my 
understanding that the ordering of this array is arbitrary -- most likely 
representing the order in which the components we added, but maybe not. 
Perhaps findComponent() should return a Collection of Components which the 
user could sort in different ways. Maybe the most useful way would be in 
screen order (top to bottom, left to right), but other ways are possible too.

6. Does SwingUtilities.windowForComponent() do what 
ComponentHelper.getWindow() already does?

7. The various Helper classes seem to be doing two different things: they 
help find Components and Windows, and they help manipulate the Components. 
This functionality should be split into distinct classes. I would avoid 
helper routines like getLabel() because Components like JLabel already have 
easy ways to get this.

8. How about breaking the Helper up along functional lines?

         Classes/methods to get the set of Windows.
         Classes/methods to get the set of Components in a Window or 
Contrainer.
         Classes/methods to filter a set of Components.
         Classes/methods to generate mouse and keyboard events.
         Classes/methods to manipulate Components.

Examples of filters are anything that uses a ComponentFinder. It just works 
on a set instead of a tree. Another filter would be one that given a set of 
Components returns the subset of enabled components.

Examples of manipulators are enterClickLeave().

9. What's the motivation for refactoring TestHelper? What problems are you 
trying to solve? What aspects of it do you like that you want to preserve?


>Are you interested in contributing to JFCUnit?

Yes.

PS. I'm writing this from home on my wife's machine. That's why the return 
address is sometimes to me and sometimes to my wife. It doesn't matter.

-Christopher Helck

RE: [Jfcunit-devel] Some questions

[Catharine H. <cr...@mi...>]

At 04:28 PM 7/4/01 +0100, Matt Caswell wrote:

> > 1) Why subclass and push your own event queue? Could you
> > track the opening
> > and closing of windows through an AWTEventListener instead? I have an
> > application which uses its own event queue and can't coexist
> > with JFCUnit.
> >
>
>A listener can only listen on a component that you have a handle on. If you
>don't have a handle on a component you can't put a listener on it. The
>custom event queue enables us to listen for open window events for windows
>that we have no handle on. We could maybe make some changes to enable us to
>optionally switch this facility off - the result of this being that you
>would have to get hold of window handles some other way.

AWTEventListeners are attached to the event queue and not a component. They 
are notified whenever an event type that they are interested in goes across 
the queue. This includes window open/close events. See the following code:

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import java.util.*;

public class Test {

     public static void main(String argv[]) {
         AWTEventListener l = new AWTEventListener() {
             public void eventDispatched(AWTEvent e) {
                 System.out.println("AWTEvent " + e);
             }
         };

         Toolkit.getDefaultToolkit().addAWTEventListener(l, 
AWTEvent.WINDOW_EVENT_MASK);


         JFrame frame = new JFrame();
         frame.setVisible(true);
         JOptionPane.showMessageDialog(null, "Hi", "Hi", 
JOptionPane.ERROR_MESSAGE);
     }
}

Here's the output I got:

AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on frame0
AWTEvent java.awt.event.WindowEvent[WINDOW_OPENED] on frame0
AWTEvent java.awt.event.WindowEvent[WINDOW_DEACTIVATED] on frame0
AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on dialog0
AWTEvent java.awt.event.WindowEvent[WINDOW_OPENED] on dialog0
AWTEvent java.awt.event.WindowEvent[WINDOW_ACTIVATED] on frame0
AWTEvent java.awt.event.WindowEvent[WINDOW_CLOSED] on dialog0
AWTEvent java.awt.event.WindowEvent[WINDOW_CLOSING] on frame0
AWTEvent java.awt.event.WindowEvent[WINDOW_DEACTIVATED] on frame0

I'd think you could create a listener to keep track of the windows and 
dialogs as they are opened and closed.
If you'd like I'd be happy to give this a try.

BTW: I haven't looked at Java 1.4 very closely yet, but I think they now 
have a way to get a set of open windows. So this whole issue may become moot.

[snip]

> > 4) Any ideas about how to setup and teardown tests that
> > involve a main
> > application?  Is there a way to end and restart the GUI thread?
> >
>
>Not sure what you mean by "involving a main application" - can you give an
>example?

I'm asking how do I write multiple tests on an application? Suppose you 
want to test login sequences. You need a test for a good login, a login 
with a bad user name, a login with a bad password, and so forth and so on. 
How do you write setUp() and tearDown() methods so that each test starts 
with a clean slate?

Thanks,
Christopher Helck

RE: [Jfcunit-devel] Some questions

[Greg H. <gho...@ya...>]

I've put my comments below...

--- Matt Caswell <mat...@mo...> wrote:
> Comments inserted below...
> 
> 
> _____ 
> This email and any attachments are confidential and are intended only for 
> the addressee. If you are not the intended recipient of this email and have 
> received it in error, please notify the sender immediately by reply email 
> and then delete it from your system. 
> 
> 
> > -----Original Message-----
> > From: C & C Helck [mailto:pp0...@mi...]
> > Sent: 02 July 2001 03:36
> > To: jfc...@li...
> > Subject: [Jfcunit-devel] Some questions
> > 
> > 
> > Hi, I'm quite interested in JFCUnit. I've browsed the code 
> > and have some 
> > questions.
> > 
> > 1) Why subclass and push your own event queue? Could you 
> > track the opening 
> > and closing of windows through an AWTEventListener instead? I have an 
> > application which uses its own event queue and can't coexist 
> > with JFCUnit.
> > 
> 
> A listener can only listen on a component that you have a handle on. If you
> don't have a handle on a component you can't put a listener on it. The
> custom event queue enables us to listen for open window events for windows
> that we have no handle on. We could maybe make some changes to enable us to
> optionally switch this facility off - the result of this being that you
> would have to get hold of window handles some other way.
> 
> 
> > 1.2) Shouldn't the event queue remove Windows from the set 
> > when windows are 
> > disposed? or made non-showing?
> > 
> 
> Possibly. Open to discussion on this one!
> 


You should be able to access non-showing windows.  After it is disposed, it would be nice to
remove it.


> 
> > 2) In the enterClickLeave() method (I may have the name 
> > wrong) you spoof 
> > mouse events and put them on the queue. Has anyone tried using the 
> > Awt.Robot class to do this instead? My guess is that spoofing 
> > will become a 
> > big pain in the butt with keystrokes.
> > 
> 
> We have not looked at awt.Robot as of yet - although someone else has
> previously suggested it. I suspect sooner or later we will look at this as
> an option.
> 


One problem with awt.Robot is the component it accesses must appear on the screen.  If you had a
component that was off-screen, or scrolled out of view, you would have to get it on screen before
you could interact with it.

I think awt.Robot is a great way to manipulate components, but it isn't necessary for most tests.



> > 3) What version of Java are you aiming for?
> 
> I am developing using Java build 1.3.0_01. As far as I am aware I don't know
> of any reason why it shouldn't work for any version of Java 1.2+, but I
> haven't tested this.
> 


I think we should be aggressive in keeping up with the latest released versions of Java and JUnit.
 This should not include pre-release or beta versions.



> > 
> > 4) Any ideas about how to setup and teardown tests that 
> > involve a main 
> > application?  Is there a way to end and restart the GUI thread?
> > 
> 
> Not sure what you mean by "involving a main application" - can you give an
> example?
> There is no way to end and restart the GUI thread at the moment. Is this a
> requirement for you?
> 
> 


We are looking at ways to stop the GUI thread.


> > 5) Why start and stop the event queue? When I've thought 
> > about writing a 
> > GUI test tool I imagined that I'd run the tests with 
> > invokeLater() and get 
> > the results via a callback.
> > 
> 
> This is effectively what is being done behind the scenes by JFCUnit. Since
> most tests would take the form...
> do something
> invokeLater()
> do something else
> invokeLater()
> do something else
> invokeLater()
> etc
> 
> ...I felt this was going to very quickly lead to unreadable code - since
> every call to invokeLater would require the creation of some (probably
> local) class. I felt using the "awtSleep" method was a lot neater.
> 
> Matt
> 
> P.S. Sorry for the dealy in responding - I have been away from email for a
> while.
> 
> 
> > Thanks for your time,
> > Christopher Helck
> > 
> > 
> > _______________________________________________
> > Jfcunit-devel mailing list
> > Jfc...@li...
> > http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> > 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

RE: [Jfcunit-devel] Some questions

[Matt C. <mat...@mo...>]

Comments inserted below...


_____ 
This email and any attachments are confidential and are intended only for 
the addressee. If you are not the intended recipient of this email and have 
received it in error, please notify the sender immediately by reply email 
and then delete it from your system. 


> -----Original Message-----
> From: C & C Helck [mailto:pp0...@mi...]
> Sent: 02 July 2001 03:36
> To: jfc...@li...
> Subject: [Jfcunit-devel] Some questions
> 
> 
> Hi, I'm quite interested in JFCUnit. I've browsed the code 
> and have some 
> questions.
> 
> 1) Why subclass and push your own event queue? Could you 
> track the opening 
> and closing of windows through an AWTEventListener instead? I have an 
> application which uses its own event queue and can't coexist 
> with JFCUnit.
> 

A listener can only listen on a component that you have a handle on. If you
don't have a handle on a component you can't put a listener on it. The
custom event queue enables us to listen for open window events for windows
that we have no handle on. We could maybe make some changes to enable us to
optionally switch this facility off - the result of this being that you
would have to get hold of window handles some other way.


> 1.2) Shouldn't the event queue remove Windows from the set 
> when windows are 
> disposed? or made non-showing?
> 

Possibly. Open to discussion on this one!


> 2) In the enterClickLeave() method (I may have the name 
> wrong) you spoof 
> mouse events and put them on the queue. Has anyone tried using the 
> Awt.Robot class to do this instead? My guess is that spoofing 
> will become a 
> big pain in the butt with keystrokes.
> 

We have not looked at awt.Robot as of yet - although someone else has
previously suggested it. I suspect sooner or later we will look at this as
an option.

> 3) What version of Java are you aiming for?

I am developing using Java build 1.3.0_01. As far as I am aware I don't know
of any reason why it shouldn't work for any version of Java 1.2+, but I
haven't tested this.

> 
> 4) Any ideas about how to setup and teardown tests that 
> involve a main 
> application?  Is there a way to end and restart the GUI thread?
> 

Not sure what you mean by "involving a main application" - can you give an
example?
There is no way to end and restart the GUI thread at the moment. Is this a
requirement for you?


> 5) Why start and stop the event queue? When I've thought 
> about writing a 
> GUI test tool I imagined that I'd run the tests with 
> invokeLater() and get 
> the results via a callback.
> 

This is effectively what is being done behind the scenes by JFCUnit. Since
most tests would take the form...
do something
invokeLater()
do something else
invokeLater()
do something else
invokeLater()
etc

...I felt this was going to very quickly lead to unreadable code - since
every call to invokeLater would require the creation of some (probably
local) class. I felt using the "awtSleep" method was a lot neater.

Matt

P.S. Sorry for the dealy in responding - I have been away from email for a
while.


> Thanks for your time,
> Christopher Helck
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel
> 

[Jfcunit-devel] Refactoring JFCTestHelper

[Greg H. <gho...@ya...>]

Mr Helck,

Thanks for reviewing the code.  Matt and I will have to discuss yor questions to see if we should
make some design changes.  We are currently make some changes to JFCTestHelper.  I would really
like you to comment on the design.  Could you take a look at
http://www.geocrawler.com/archives/3/13039/2001/6/0/6048488/  and tell us what you think?

Are you interested in contributing to JFCUnit?

Thanks,
Greg



--- C & C Helck <pp0...@mi...> wrote:
> Hi, I'm quite interested in JFCUnit. I've browsed the code and have some 
> questions.
> 
> 1) Why subclass and push your own event queue? Could you track the opening 
> and closing of windows through an AWTEventListener instead? I have an 
> application which uses its own event queue and can't coexist with JFCUnit.
> 
> 1.2) Shouldn't the event queue remove Windows from the set when windows are 
> disposed? or made non-showing?
> 
> 2) In the enterClickLeave() method (I may have the name wrong) you spoof 
> mouse events and put them on the queue. Has anyone tried using the 
> Awt.Robot class to do this instead? My guess is that spoofing will become a 
> big pain in the butt with keystrokes.
> 
> 3) What version of Java are you aiming for?
> 
> 4) Any ideas about how to setup and teardown tests that involve a main 
> application?  Is there a way to end and restart the GUI thread?
> 
> 5) Why start and stop the event queue? When I've thought about writing a 
> GUI test tool I imagined that I'd run the tests with invokeLater() and get 
> the results via a callback.
> 
> Thanks for your time,
> Christopher Helck
> 
> 
> _______________________________________________
> Jfcunit-devel mailing list
> Jfc...@li...
> http://lists.sourceforge.net/lists/listinfo/jfcunit-devel


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

[Jfcunit-devel] Some questions

[C & C H. <pp0...@mi...>]

Hi, I'm quite interested in JFCUnit. I've browsed the code and have some 
questions.

1) Why subclass and push your own event queue? Could you track the opening 
and closing of windows through an AWTEventListener instead? I have an 
application which uses its own event queue and can't coexist with JFCUnit.

1.2) Shouldn't the event queue remove Windows from the set when windows are 
disposed? or made non-showing?

2) In the enterClickLeave() method (I may have the name wrong) you spoof 
mouse events and put them on the queue. Has anyone tried using the 
Awt.Robot class to do this instead? My guess is that spoofing will become a 
big pain in the butt with keystrokes.

3) What version of Java are you aiming for?

4) Any ideas about how to setup and teardown tests that involve a main 
application?  Is there a way to end and restart the GUI thread?

5) Why start and stop the event queue? When I've thought about writing a 
GUI test tool I imagined that I'd run the tests with invokeLater() and get 
the results via a callback.

Thanks for your time,
Christopher Helck