Eclipse GUI testing tool? - swt

what do you use for automatic GUI testing an eclipse rcp app?
I checked Xored Q7 which looks pretty awesome, but it doesn't work 100%, the same goes for froglogic squish. I need something for testing SWT/JFACE and GEF(but i could live without GEF support). Is there any other mature testing tool?

SWTBot is designed to test eclipse RCP (SWT&JFace) applications. It is still in incubation though. The last time I used it, it had some issues, but it's almost 3 years back, so I hope the maintainers have made some progress.

I'm in charge of Xored's Q7 development, and we'll be very interesting learning more about your test case (where Q7 does not work 100% perfectly). Can you please email me or Xored support and I'm pretty sure we'll resolve that problems very fast.
Thank you,
Andrey

I'm using SWTBot in the last year and it works fine. You must know that there is no record function, but writing the tests per hand isn't so difficult.There are some limitations regarding native dialogs, which cannot be tested using SWTBot.
There are another two GUI test frameworks from Bredex - Jubula / GUIDancer. Last year I have tried the Jubula, but without success to understand how it works.

Related

Eclipse RCP opinions

I am working on a standalone Eclipse RCP product. My team replaced another team that wrote the infrastructure of the product.
I and my team leader aren't very happy with the Eclipse RCP framework because we feel that it is just very hard to get it to work correctly.
This is because:
The GUI building tools are annoying. XWT is buggy (bindings don't
always work, can't add scrollbars, and this is only the half of it).
SWT also isn't very exciting. I don't like the API and it doesn't
have too many exciting widgets.
Eclipse IDE itself is buggy (we
have to restart it every few hours). We are using eclipse juno. When
we tried to upgrade to luna we ran into some unsolvable issues:
Eclipse Luna: Handlers' #CanExecute methods not called due to wrong context
We have lots of weird bugs (e.g. eclipse looks at wrong selection
service and much more).
Even though there is support and
documentation, we find that it is kind of poor compared to other
solutions out there.
Due to the above, developement of simple
things seem to take too long. We have another .NET product which is
much easier to write.
However, google didn't seem to badmouth eclipse rcp... So I wanted to ask, what do you guys think about it? Do you find it easy to use? Do you find it flexible?
Just want to hear some opinions.
Thanks!!!

How to test the UI of an Eclipse Juno RCP

We're developing an Eclipse-based RCP. Recently we've updated to Eclipse Juno and currently we focus on quality, which of course brought automated tests into focus, since the application is quite big and the testing effort delays releases.
We're already writing JUnit tests, but I'm more interested in UI tests. With older Eclipses this would not be a problem. There are plenty of good test frameworks around. Unfortunately with Juno everything changed due to the added ability to switch out the default SWT UI by Swing or JavaFX (at least this is what I've understood about the changes causing problems)
So most of the test tools don't work properly anymore. From past experiences it seems that:
SWTBot seems to get not much love lately and is very unstable (can't find elements in certain versions)
Window Tester seems quite good, but has a lot of problems identifying an element during the test run (especially with pop-ups such as content assist or tool tips)
Apparently Froglogics Squish supports Juno, but since a license costs about 2,5k Euro I have to pass
The same seems to be the case for QF-Test (too expensive).
This leaves Jubula (or GUIDancer, which is the commercial Jubula), which we've tried in the past, but which had similar problems as Window Tester and SWTBot (unstable in terms of changes to the Eclipse platform and difficulties to detect some elements)
I need to know, which tool to focus on / trust in. Does anybody have experience with one of the tools or is even currently testing a Juno RCP (or Juno itself for that matter)? Or does anybody know how Eclipse tests their own platform (if they even do it atm)?
Searching for information related to "test", "Juno" and "UI/GUI" only brings up the commercial products.
For me it is important, to find a tool, where I can use the developed test cased even in future releases, which means: A framework project, which has some support of the community to be able to adapt quickly. Also it is important to also find stuff like tool-tips, overlays or content assists/suggestions) - similar to a Selenium compared to basic HTMLUnit.
At this point I don't even care too much about integration, reporting or compliance to standards..
You can find a comprehensive table of GUI-Testing tools in the Eclipse Wiki:
http://wiki.eclipse.org/Automated_Testing#UI_tests
One important decision you have to make is, if you want to use your mouse to record/create tests (Jubula, QFTest, ...), if you want to be able to hand-write test-code (SWTBot, ...), or if you want to be able to do both (WindowTester Pro, ...).
Eclipse Juno is rather new, and I would expect problems with all of the listed tools, however the migration should not take that long since most of these tools mainly focus on testing SWT-widgets and Juno still uses SWT. So far I have not heard from any RCP Application seriously using JavaFX other than for technical demos, but I would be curious to see them!
The problem I think, is rather that testing Eclipse is hard and GUI-testing is especially hard.
You might want to have a look at this study which finds and explains the major problems:
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-010.pdf
If you believe this study, JUnit-testing is usually preferable to GUI-testing. Well, with Juno you have the big advantage that Unit-testing Eclipse now is easier than it ever was because the framework switched from inheritance and singletons to dependency injection, which makes it far more testable.
I'd suggest you too look at Xored's Q7, which is used for GUI testing of some of Eclipse projects including Eclipse DLTK, Eclipse LDT, Eclipse Tigerstripe and the tool is just perfect : it let you develop dozens of UI tests per day per engineer, and do not have stability and incorrect-recording problems. It's designed specially and only to test Eclipse-based apps and obviously the best in the niche.
However it costs money, which can be a blocker for you (like squish), but they have a free Community version, which is enough for most of use-cases. As well as those Xored guys just introduced pay-per-testexecution pricing model -- the tools will be free and you have to pay as you go only per tests executed monthly (less than 5000 is free). More about new model is here eclipse-testing.com

drag and drop environment to start developing in gwt

is there any drag and drop environment to work with GWT widgets.
or any user friendly IDE or plugin on IDE's
i remember using some thing like MyEclips for developing Hibernate was better then working with .xml files.
The Eclipse-based WindowBuilder Pro supports GWT and is now free, courtesy of Google.
I tried GWT Designer, http://code.google.com/webtoolkit/tools/gwtdesigner/index.html, but I think for now I'll stick to code the guis myself by hand.
The main reasons are:
Sometimes, it takes a little while (longer than I can wait) to load the design mode.
Sometimes it breaks after you modify code underneath.
Sometimes, does not do what you expect it to do.
I would suggest you giving it a try and see if it works out for your needs.
In my opinion, the experience using it has been frustrating than encouraging.

Is eclipse visual editor dead?

The Eclipse Visual Editor project seems to be dead, no commits, no updates. Any one know what is happening?
Update 2: The project has been archived (i.e. dead) since June 2011 again.
Update: The project has been revived and is now under active development again.
Its pretty much dead due to a lack of developer support. Here are some recent posts from their mailing list talking about a lack of movement on the project.
What's happening? It's called NetBeans, and it's already happened.
I'm going to get voted down for this but they know it's true. I love eclipse and have used it religiously since I started Java. I'm not saying I like Netbeans, it's just all I hear whenever the concept of a Java visual editor is brought up.
The Jigloo plug-in for Eclipse is a pretty great alternative to the Visual Editor. Though still not quite as nice as the Netbeans GUI editor it is fairly robust and fully featured, especially compared to what was available in the Visual Editor plug-in. Definitely should give it a shot.
Actually NetBeans has gotten MUCH MUCH better. I've used Eclipse, Netbeans and IntelliJ for a few years each, and NetBeans is at least as good (performance, usability & features) as the others now.
It's also improving more quickly than the others are.
They have people working full time on alternate language support, so you'll find they have the best Ruby support in the industry, and I believe Python is about to become that good as well.
Of course, Eclipse still has that crazy-cool todo list that remembers which files you worked on for each bug and can take you back to the set of files/edits for any bug you've worked on, that's really amazing to use and I don't think it's available on either of the other platforms.
--- Revision from years in the future ---
I have used Netbeans more and really have to give the award to Eclipse. The difference has been in vertical programming environments--most will target Eclipse and ignore netbeans. You rarely need these, but when you need them there is often no way around them. If Netbeans does have an equivalent, it's often buggy to the point of not being usable, generally the biggest issue is emulator support.
You won't run into these unless you are working in a specific industry--Android development is one, the primary drive was to support Eclipse, NB seems to trail. Another I've worked on is in the TV/Cable industry.
For raw java development, however, I'd still give Netbeans a little edge because it's the environment that was targeted and supported by sun.
Visual Editor is doing a new release, 1.4, on September 16. Installation instructions for the RC are here:
http://wiki.eclipse.org/VE/Update
FWIW, the project did stall for a while. But there is a new, and relatively diverse group of folks working on it again. Most of the recent work is concerned with making the new release compatible with Eclipse Galileo.
It's officially dead as of May 2011. It's archived here, but slow to download and tricky to install. Instead, there's a new editor, WindowBuilder Pro.
Currentlty Google have Open Sourced the Windows Builder Pro. It seems nice
yeap,
http://www.eclipsezone.com/eclipse/forums/t91368.html
Yes, sadly, it is dead. Looking at the aforementioned email threads regarding it's revival I get the feeling that even if it does get picked up it will quickly collapse under the weight of some new requirements ("make it universal, edit everything from SWT to HTML").
WindowBuilder can be a good alternative. I had several problems with VE and I end up with WindowBuilder who worked for me perfectly.
http://www.eclipse.org/windowbuilder/

Are there any good Continuous Testing plugins for Eclipse out right now?

I've used the MIT Continuous testing plugin in the past, but it has long since passed out of date and is no longer compatible with anything approaching a modern release of Eclipse.
Does anyone have a good replacement? Free, naturally, is preferred.
I found that Infinitest now has an Eclipse plugin that seems to work pretty well.
There is a list in this Ben Rady article at Object Mentor: Continuous Testing Explained. Unfortunately the only Eclipse tool appears to be CT-Eclipse which is not currently maintained either.
There is also Fireworks for IntelliJ and Infinitest which is not IDE specific but also has some IntelliJ integration.
My experience is that continuous testing within the IDE can become unwieldy and distracting, so I prefer to use something like CruiseControl to do this kind of testing. One tool I have found very useful is EclEmma, which gives you a very fast coverage turnaround for your units, helping you to decide when you have finished testing a particular area of the code.
Infinitest decides what tests it wants to run. Often it runs the wrong ones. Green bar sometimes good, sometimes meaningless.
I've had good experience with infinitest on a small and simple project. I've not run into any issues with it and find it fast and helpful.
I also use Infinitest (and voted for one of its answers), but I wanted to add another approach, which relies on the build server. Whenever you want to implement something, create a branch in your VCS, do your changes, commit to your branch. If you have a build server configured, which runs unit tests on every checkin, your unit tests are then run on the build server without actually having polluted the trunk (or HEAD, whatever you call it) and without you waiting for the test run to finish.
I admit that this is not really continuous unit testing in the sense you asked the question, but for large projects or large test suites even a "normal" continuous test runner may slow you down way to much.
For small projects I also recommend Infinitest or CT Eclipse.