| java.lang.ClassCastException when running SWTBot tests in headless mode [message #654980] |
Thu, 17 February 2011 15:56  |
Eclipse User |
|
|
|
Hi all,
at the moment I am playing with SWTBot which I think is great tool. Everything is working like a charm when running the tests from Eclipse. But when I try to run the tests in headless mode on exported RCP app I am facing serious problem.
RCP app starts correctly but no test is performed on it.
There is this exception in the console:
[java] Exception in thread "WorkbenchTestable" java.lang.NoClassDefFoundError junit/framework/TestListener
which seems to be raised often (Troubleshooting section of SWTBot)
But in the log of the test there is other exception:
java.lang.ClassCastException: "<NameofTheClass>" cannot be cast to org.eclipse.core.commands.IHandler
at org.eclipse.ui.internal.handlers.HandlerProxy.loadHandler(HandlerProxy.java:334)
at org.eclipse.ui.internal.handlers.HandlerProxy.isEnabled(HandlerProxy.java:304)
at org.eclipse.core.commands.Command.isEnabled(Command.java:833)
at org.eclipse.core.commands.Command.setHandler(Command.java:996)
at org.eclipse.ui.internal.handlers.HandlerAuthority.updateCommand(HandlerAuthority.java:459)
at org.eclipse.ui.internal.handlers.HandlerAuthority.activateHandler(HandlerAuthority.java:249)
at org.eclipse.ui.internal.handlers.HandlerService.activateHandler(HandlerService.java:120)
at org.eclipse.ui.internal.handlers.HandlerService.activateHandler(HandlerService.java:112)
at org.eclipse.ui.internal.handlers.HandlerService.activateHandler(HandlerService.java:107)
at org.eclipse.ui.internal.handlers.HandlerPersistence.readDefaultHandlersFromRegistry(HandlerPersistence.java:250)
at org.eclipse.ui.internal.handlers.HandlerPersistence.reRead(HandlerPersistence.java:204)
at org.eclipse.ui.internal.handlers.HandlerPersistence.read(HandlerPersistence.java:158)
at org.eclipse.ui.internal.handlers.HandlerService.readRegistry(HandlerService.java:186)
at org.eclipse.ui.internal.handlers.HandlerServiceFactory.create(HandlerServiceFactory.java:61)
at org.eclipse.ui.internal.services.WorkbenchServiceRegistry.getService(WorkbenchServiceRegistry.java:102)
at org.eclipse.ui.internal.services.ServiceLocator.getService(ServiceLocator.java:174)
at org.eclipse.ui.internal.Workbench$43.runWithException(Workbench.java:1675)
at org.eclipse.ui.internal.StartupThreading$StartupRunnable.run(StartupThreading.java:31)
at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:178)
at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150)
at org.eclipse.swt.widgets.Display.syncExec(Display.java:4251)
at org.eclipse.ui.internal.StartupThreading.runWithoutExceptions(StartupThreading.java:94)
at org.eclipse.ui.internal.Workbench.initializeDefaultServices(Workbench.java:1671)
at org.eclipse.ui.internal.Workbench.init(Workbench.java:1318)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2312)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at com.pikeelectronic.tibco.makedoc.gui.rcp.impl.Application.start(Unknown Source)
at org.eclipse.swtbot.eclipse.junit4.headless.UITestApplication.start(UITestApplication.java:53)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:382)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504)
at org.eclipse.equinox.launcher.Main.run(Main.java:1236)
at org.eclipse.equinox.launcher.Main.main(Main.java:1212)
at org.eclipse.core.launcher.Main.main(Main.java:30)
Application Started: 4985
!ENTRY org.eclipse.equinox.p2.ui.sdk 2 0 2011-02-17 21:36:47.625
!MESSAGE Could not locate the running profile instance
Target class is not implementing IHandler interface, but I don't understand why it is necessary to cast when in Eclipse everything is working well.
Using SWTBot 2.0.2 and Eclipse 3.4.0.
Any help will be appreciated.
JJ
[Updated on: Thu, 17 February 2011 16:01] by Moderator |
|
|
|
|
|
|
|
| Re: java.lang.ClassCastException when running SWTBot tests in headless mode [message #658054 is a reply to message #658027] |
Sat, 05 March 2011 11:37  |
| Eclipse User |
|
|
|
On 3/5/11 12:29 AM, Jiri Janecek wrote:
> After some time I returned to GUI testing with SWTBot. I played with
> many scenarios to determine conditions when everything is working well.
>
> Tested product includes one feature which contains custom plugins. As I
> said I wouldn;t like to mix tests and product code, so I created tests
> feature and added this feature as optional to feature which forms
> product. This feature is built separately from main build process.
+1 so far. We have 2 product files, one for production(without test
features) and one with the test features and dependencies.
The only difference is that we build the production product after the
test product is built, which means that if the tests break, the
production build is never generated forcing devs to fix the problem as
soon as it is detected.
<snipped/>
> If I manage to have everything in the test feature, tests become
> completely hidden from developers and they will not need to add swtbot
> bundles in their platforms.
>
> Is there any way how to achieve this?
[Putting my consultant hat on...]
This is unfortunately a people problem, and tools might be a bad idea to
solve them, to the point that people will start hating the tool.
I feel the correct way to address this issue would be to find out why
devs want to hide away the test bundles and encourage them to write very
simple tests to document the feature they are working on. These need not
cover any corner cases, but just go through some happy paths to ensure
that basic functionality works before checking in code.
A set of a handful of such smoke tests that run in under 2-3 minutes to
test basic features of the application to ensure that nothing obvious
has been broken before someone checks in can prove to be very valuable
to developers.
--
Ketan
http://ketan.padegaonkar.name | http://eclipse.org/swtbot | @ketanpkr
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.25676 seconds
Home
), so this is correct now.