|Open Bugzilla tickets|
|Open Gerrit reviews|
- 1 Troubleshooting
- 1.1 SWTBot fails with"swtbottestapplication" could not be found in the registry
- 1.2 WidgetNotFoundException when stepping through SWTBot test in Eclipse debugger
- 1.3 Headless Testing Troubleshooting
SWTBot fails with"swtbottestapplication" could not be found in the registry
If you get an error like:
java.lang.RuntimeException: Application "org.eclipse.swtbot.eclipse.core.swtbottestapplication" could not be found in the registry. The applications available are: some.long.list.of.application.ids
Then the most common cause is that the target platform does not have the "org.eclipse.swtbot.eclipse.core" plugin. If you're certain that you have this plugin, but the error persists. Try running with -consoleLog -debug options turned on while running the tests. This would most probably tell you about a missing dependency that causes the plugin to not load.
WidgetNotFoundException when stepping through SWTBot test in Eclipse debugger
If you set a debugger breakpoint in an SWTBot test and then step through it, you may see a WidgetNotFoundException from an SWTBot call that should easily succeed, like
SWTWorkbenchBot bot = new SWTWorkbenchBot(); ... bot.viewByTitle( "MyView" )
This is because when the debugger is in focus, your application is out of focus, which prevents SWTBot from finding its widgets.
You may be able to debug your problem by setting any breakpoints after the SWTBot calls you're interested in, and don't expect to be able to step across subsequent SWTBot calls. However this is extremely limited because you can only debug your code after one call to a SWTBot method and before the next call to an SWTBot method.
99% of the time you will need to debug into the SWTBot code to see why it is behaving as it is. Because of that debugging SWTBot is very difficult. The best is if you use an external debugger that does not take focus on the target machine. Failing that another technique is to create a static flag that is turned on just before the call to the SWTBot you want to debug and then check this flag inside the SWTBot code, after the active shell has been obtained but before the code you would like to debug.
Pro-Tip: If you're using Linux, you should use a Xephyr and run your tests into the Xephyr DISPLAY to prevent from this focus issue. Read more at SWTBot/Automate_test_execution#use_another_DISPLAY_to_save_time
Headless Testing Troubleshooting
Exception in thread "WorkbenchTestable" java.lang.ClassCastException: org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter at org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner .run(EclipseTestRunner.java:331) at org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner .run(EclipseTestRunner.java:208) at org.eclipse.swtbot.eclipse.junit4.headless.UITestApplication .runTests(UITestApplication.java:115) at org.eclipse.ui.internal.testing.WorkbenchTestable$1.run(Work benchTestable.java:68) at java.lang.Thread.run(Thread.java:595)
The primary reason for this to happen is because you are using the incorrect version of an ant-junit fragment. If you are using swtbot, please ensure that you are not using the eclipse-test-framework's ant-junit fragment org.eclipse.ant.optional.junit_*.jar. Also ensure that you are using the right version of swtbot's ant-junit fragment that suits your junit version.
[java] Exception in thread "WorkbenchTestable" java.lang.NoClassDefFoundError: junit/framework/TestListener [java] at java.lang.ClassLoader.defineClass1(Native Method) [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:620) [java] at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183) [java] at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:576) [java] at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:546) ... [java] at org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner.createFormatter(Unknown Source) [java] at org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner.createAndStoreFormatter(Unknown Source) [java] at org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner.run(Unknown Source) [java] at org.eclipse.swtbot.eclipse.junit4.headless.UITestApplication.runTests(Unknown Source) [java] at org.eclipse.ui.internal.testing.WorkbenchTestable$1.run(WorkbenchTestable.java:68) [java] at java.lang.Thread.run(Thread.java:619)
If you're using junit3, then the stacktrace above will contain "org.eclipse.swtbot.eclipse.junit4.headless" in the stacktrace.
The following description assumes that you're using junit4, but the instructions will be similar for junit3 users. If you're not already on junit3, you're highly encouraged to move to junit4.
There could be various reasons for this error, please verify the following and post on the newsgroup if neither of these work:
- Verify that the command line used to execute the tests is similar to the one described here Ant Command Line. Add or remove arguments at your own risk only if you know what they are doing.
- That your test plugin depends on junit4. I'd recommend a 'Requires-Bundle' vs. 'Import-Package' dependency.
- Run the tests again with the "-consoleLog -debug" arguments. This will print some more useful output about why these tests did not work.
- That the correct version of junit4 is present, and no dependencies are missing.
- That there is only one version of junit4 in your plugins directory.
- That there in no "org.eclipse.swtbot.eclipse.junit3.headless" fragment and "org.eclipse.swtbot.ant.optional.junit3" present in your plugins directory. junit3 and junit4 do not seem to mix well in eclipse.
- That you do not have "org.eclipse.ant.optional.junit" or "org.eclipse.test" from the eclipse testframework jars. Infact, if possible, do not install the eclipse test framework into your SWTBot test environment.
If none of these fixes the issue, please see OSGi Console to diagnose this on the command line. If the diagnosis on the OSGi console does not seem right, please ask a question on the support forum. Do not forget to add the complete output of the console (with "-consoleLog -debug -noExit -console" arguments turned on), along with anything else that you found using the OSGi Console might help.