For some reason, our functional tests fail because they time out. Screens which ought to be appearing in a timely manner aren’t visible. Buttons which are enabled when the screen is populated are still disabled when the test tries to click them. I’ve been attempting to get to the bottom of this problem with limited success.
This has prompted me to look at the way in which Abbot is getting hold of the window. As far as I can tell, when a test waits for a window to appear, Abbot loops, checking periodically (once every 10 ms) to see if it’s there, until it times out.
To me, this is the behaviour of a small, bored, annoying child sitting in the back seat of a car, asking “Are we there yet? Are we there yet? Are we there yet?” until the CPU driving is so distracted that it forgets where it was trying to go in the first place. This may have something to do with our mysterious timeouts; I’m not sure. Putting a longer wait in our test fixtures has definitely improved my chances in the fight for the green bar.
Is there a reason why Abbot was implemented this way? Is there no way to, say, attach a listener to events such as a window opening? Can Swing tell us, “Get out; we’re here,” instead of us having to ask repeatedly?
If there are no sensible reasons, and no one objects to a harness which hammers slightly less on my poor little CPU, I may give it a shot. Another optional package for JBehave, perhaps. I’ve always wanted a harness which waits for arbitrarily selected events anyway; there are plenty of threaded test scenarios in which I could use it.
Liz Keogh, lunivore 
Am wondering why you are using Abbot (which is rather immature) and not Marathon ? Are you getting some features in Abbot not available in Marathon ?
We evaluated both of these, and decided to go with Marathon coz it’s so easy, esp from Analysts/Customer standpoint, and integrates well w/ our Agile style of development.
-Raghu Havaldar
Write a Decorator for the L&F factory, so that you can intercept creation of new objects. At that point, you can register to listen to GUI objects, such as windows, as they are created.
If need be, you can decorate those objects as well, allowing you to listen to calls such as “setVisible”.
Robert.
When I arrived on this project they had moved across from Marathon to Abbot. I’m not sure why – they were using the Python scripts for Marathon, and described it to me as “flaky”.
I shall look into it; thanks. In the meantime I shall continue with my gui harness efforts as it’s fun, and I’m learning a lot. 🙂
Is that better than listening to the events on the AWT thread?
At the moment, I’m listening to windows being opened and closed, and will use a component hierarchy navigator of some kind to look through the children of the windows I grab. The AWT thread doesn’t notify me until the window is fully opened (I hope!). Also means that I don’t have to override any L&F being used by the project under test (there’s one on my day-job project).
It’s a cool idea, though, and I shall bear it in mind. Cheers!