tag:blogger.com,1999:blog-3339316202894508517.post7162250899012633901..comments2008-08-14T18:37:14.552-07:00Brian Duffhttp://www.blogger.com/profile/15591692569924908268noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-3339316202894508517.post-42927890183497627502008-08-13T18:48:00.000-07:002008-08-13T18:48:00.000-07:00In our book "Swing Extreme Testing" we develop a lot of utility code for testing user interfaces. Anyone seriously interested in thoroughly testing their Java desktop application should have a look. Anyhow, we have an improved Robot ("Cyborg") that makes clicking, dragging and dropping, using tables, lists etc. pretty straightforward. We develop another class ("UI") for safely interacting with Swing components from the test thread. TL.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-25935573037130585272007-06-13T07:26:00.000-07:002007-06-13T07:26:00.000-07:00Brian,<BR/><BR/>Is it possible to test drag and drop, and focus tracking this way?<BR/><BR/>BruceBruce Alspaughhttp://www.blogger.com/profile/16969753902392777881noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-7119623836871193332007-04-22T00:45:00.000-07:002007-04-22T00:45:00.000-07:00I guess I've seen too many developers over the years kind of raise their hands and declare unit testing a bust on Swing and end up just writing functional tests instead because it's "easier". <BR/><BR/>I've found unit testing of swing code to be incredibly effective, and I'm less than impressed by some of the functional test frameworks out there (although I like FEST a lot of course :) ). <BR/><BR/>BrianBrian Duffhttp://www.blogger.com/profile/15591692569924908268noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-81546400605207546952007-03-09T08:43:00.000-08:002007-03-09T08:43:00.000-08:00Hi Brian,<BR/><BR/>Obviously I'm not describing a unit test. It is a functional test. What I am saying is that although unit test is useful, you need functional tests as well.<BR/><BR/>Cheers,<BR/>Alex.alexRuizhttp://www.blogger.com/profile/17146635182338081808noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-49652478050661123472007-03-08T12:49:00.000-08:002007-03-08T12:49:00.000-08:00And make sure all your tests happen on the EDT or you might run into some nasty surprises :)Romain Guyhttp://www.blogger.com/profile/10487633154806940620noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-32667973506052485122007-03-08T01:04:00.000-08:002007-03-08T01:04:00.000-08:00Hi Alex,<BR/><BR/>I agree that needs to be tested. But what you are describing is not a unit test.<BR/><BR/>Thanks,<BR/>BrianBrian Duffhttp://www.blogger.com/profile/15591692569924908268noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-63247930619892721262007-03-07T11:48:00.000-08:002007-03-07T11:48:00.000-08:00Hi Brian,<BR/><BR/>Pretty interesting blog entry. Testing GUI components in isolation can be helpful. I don't agree with your assertion "no Robot is required" . It is easy to test "normal" (non-GUI) classes/components in isolation because the actual users of those classes are...other classes. We can say that the unit test simulates the usage of a normal class perfectly. The ultimate test for GUI-related stuff should include simulation of a user actually using the GUI component. An such user is a person. Hence we need a "Robot" for that.<BR/><BR/>Cheers,<BR/>Alex.alexRuizhttp://www.blogger.com/profile/17146635182338081808noreply@blogger.comtag:blogger.com,1999:blog-3339316202894508517.post-83503328932976686142007-03-07T08:02:00.000-08:002007-03-07T08:02:00.000-08:00Brian,<BR/><BR/>Your are not entirely correct that you have to see the components when testing the UI. Take a look at the following entry in the FAQ:<BR/><BR/>http://abbot.sourceforge.net/doc/FAQ.shtml#q203<BR/><BR/>On Linux you can quite happily create virtual displays that are not bound to a monitor.<BR/><BR/>Cheers,<BR/><BR/>GerardGerardhttp://www.blogger.com/profile/16521924431312439170noreply@blogger.com