On 11-Jul-08, at 6:59 AM, Somesh Sasalatti wrote:
> I currently have 3.3.1.1 running with the released version of
> swtbot and things work fine.
>
> however, if I use 3.3.2 with released version, tests don't run
> because apache.commons.logging.x jar that is with the swtbot plugin
> conflicts with what is already there in eclipse. It might be a good
> idea to remove this.
Can you define "don't run" ? In any case, as you've mentioned,
commons.logging is now removed, and logging happens via log4j directly.
> if I use 3.3.2 with the nightly, the logging problem goes away but
> tests fail on several accounts
> 1) bot.table.select("something") used to simulate a double click in
> 3.3.1 and in 3.3.2 only selects it.
This behavior is because SWTBotTable#selectNotify() would send
Selection and DefaultSelection, which caused an effect of a
doubleclick
(http://fisheye3.atlassian.com/browse/swtbot/trunk/net.sf.swtbot.finder/src/net/sf/swtbot/widgets/SWTBotTable.java?r1=647&r2=713
)
Doubleclick has now been added in trunk for the 1.2 release
(http://fisheye3.atlassian.com/browse/swtbot/trunk/net.sf.swtbot.finder/src/net/sf/swtbot/widgets/SWTBotTable.java?r1=503&r2=647
)
> 2) bot.button("finish").click() on a wizard clicks the finish button
> but doesn't wait for the click operation to finish. here's an example.
> the pseudo code goes like this:
> open the wizard.
> fill in what you need.
> bot.button("finish").click();
>
> assert( project exists)
>
> now previously in 3.3.1 with the released plugin the assert would
> not execute till the bot.button("finish").click(); finished but in
> 3.3.2 with the latest nightly, it doesn't seem to wait. so if it
> takes a while to create the project, the assert will fail.
> any ideas on what's happening.
> swt changed? 3.3.2 handles something differently ?
> bug in nightly?
For this particular change I'd recommend something like:
(http://fisheye3.atlassian.com/browse/
~raw,r=trunk/swtbot/trunk/net.sf.swtbot.eclipse.finder.test/src/net/sf/
swtbot/eclipse/finder/widgets/helpers/NewJavaProject.java)
The reason being the click() and select() kind of APIs do not wait,
but just do a bunch of asyncExecs() to notify the UI thread and move
on. I've looked at SVN history for SWTBotButton, AbstractSWTBot, and
UIThreadRunnable for anything that could have caused this change but
could not find anything.
It's hard to be able to comment on this, but you'll need to try 1.1 on
both 3.3.1, and 3.3.2 and see what changed between SWT 3.3.1 and
3.3.2, similarly try the nightly with 3.3.1 and 3.3.2 to see how
SWTBot trunk changes with respect to the previous release 1.1.
-- Ketan
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
SWTBot-users mailing list
SWTBot-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swtbot-users
http://swtbot.org/ - a functional testing tool for SWT/Eclipse
