Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


Update Sites
Mailing List
Open Bugzilla tickets
Open Gerrit reviews
Browse Source
Continuous Integration


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.

No active Shell when running SWTBot tests in Xvfb

If you get an error like:

org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: The widget was null.
 	at org.eclipse.swtbot.swt.finder.widgets.AbstractSWTBot.<init>(
 	at org.eclipse.swtbot.swt.finder.widgets.AbstractSWTBotControl.<init>(
 	at org.eclipse.swtbot.swt.finder.widgets.SWTBotShell.<init>(
 	at org.eclipse.swtbot.swt.finder.widgets.SWTBotShell.<init>(
 	at org.eclipse.swtbot.swt.finder.SWTBotFactory.activeShell(

Then a workaround is to force activation of the Shell at the beginning of your test:

UIThreadRunnable.syncExec(new VoidResult() {
  public void run() {

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"File").menu("Open File...").click();

This is because your application or the shell that corresponds to bot handle is out of focus, which prevents SWTBot from finding its widgets. Try force activation of the application or the specific shell through code just before getting the widget.

public Shell getShell(final String shtitle) {
			final Shell[] shells = bot.getFinder().getShells();
			return (Shell) UIThreadRunnable.syncExec(bot.getDisplay(), new WidgetResult<Shell>() {
				public Shell run() {
					for (Shell s : shells) {
						String title = s.getText();
						if (title.contains(shtitle)){						
							return s;
					return null;

SWTBotShell ss = new SWTBotShell(getShell("My Shell"));
ss.activate().bot().menu("File").menu("Open File...").click();

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:
    at  org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner .run(
    at  org.eclipse.swtbot.eclipse.junit4.headless.EclipseTestRunner .run(
    at  org.eclipse.swtbot.eclipse.junit4.headless.UITestApplication .runTests(
    at  org.eclipse.ui.internal.testing.WorkbenchTestable$

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.

See Ant Setup and this thread for more up-to-date information on setting up dependencies.

java.lang.NoClassDefFoundError: junit/framework/TestListener

[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(
[java]     at  org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(
[java]     at  org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(
[java]     at  org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl( 
[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 Source)
[java]     at org.eclipse.swtbot.eclipse.junit4.headless.UITestApplication.runTests(Unknown Source)
[java]     at org.eclipse.ui.internal.testing.WorkbenchTestable$
[java]     at

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.

Back to the top