Community
Participate
Working Groups
Migrate SWTBot so that its plain SWT based tests use JUnit 4.5. The plugin tests must *not* be migrated because Eclipse Testing Framework does not support JUnit 4.5 yet, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=153429. After the migration is finished the existing tests from SWTBot users that use JUnit 3.8.x (or 4.x) must still continue to work. The migration covers SWTBot test classes and perhaps its build scripts concerning JUnit. Clone the SWTBot repository from http://github.com/ketan/swtbot and commit the changes for this issue, or attach a patch file to this bug when it is finished. Run the tests before starting the migration and after the migration is finished. Compare them. The test result must be the same.
@Ketan Padegaonkar Do you want the test methods name to be in JUnit 4 style? For example instead of "testAddsItemsInOrder" just "addsItemsInOrder"?
P.S.: I will migrate it and finish it by the end of this week as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=259787.
I also managed to port the eclipse-test-framework to use junit4 (additional plugins available in trunk) I've checked this in into the repository, and have moved the eclipse tests to junit4, you should be able to pull these changes into your working copy from my github.
Should the non UI test classes like "org.eclipse.swtbot.swt.finder.collections.OrderedSetTest" be run with BlockJUnit4ClassRunner? I suggest this because the screenshots are not meaningful for non-UI tests.
I discovered that it is a lot of work to migrate SWTBot tests to JUnit 4. No way for me to finish it this week. Can we limit this in some way? I am wiling to help, but to migrate all of it soon is too much for me. Maybe I can take care of some plugins after you migrate one plugin? So I would have a example and know very good how you imagine it to be. For example I had doubts how to use SWTBotApplicationLauncherClassRunner. I think it is not really needed since subclassing AbstractSWTTestCase does the job already. AbstractSWTTestCase can be migrated to JUnit 4 by not let it subclass any other class. But if I do it this way and you don't like it, then it be for nothing. I tried to use SWTBotApplicationLauncherClassRunner and tried to migrate the test classes for it, but I got entangled in it and had to restart the process. A simple patch would be to migrate all SWTBot test classes to JUnit 4, which sublass TestCase. Its a bit too much for me in too short time. I underestimated it.
(In reply to comment #4) > Should the non UI test classes like > "org.eclipse.swtbot.swt.finder.collections.OrderedSetTest" be run with > BlockJUnit4ClassRunner? I suggest this because the screenshots are not > meaningful for non-UI tests. Yes, if something directly extends from TestCase, it makes sense to run it using that runner, but then again, lets not bother with trivia, because these tests almost always never break :)
(In reply to comment #5) > Can we limit this in some way? I am wiling to help, but to migrate all of it > soon is too much for me. Maybe I can take care of some plugins after you migrate > one plugin? So I would have a example and know very good how you imagine it to > be. Don't worry too much about things, take your time, file patches as and when you have a few tests, so that you don't have too many merge conflicts. > For example I had doubts how to use SWTBotApplicationLauncherClassRunner. I > think it is not really needed since subclassing AbstractSWTTestCase does the job > already. AbstractSWTTestCase can be migrated to JUnit 4 by not let it subclass > any other class. But if I do it this way and you don't like it, then it be for > nothing. +1. Migrating AbstractSWTTestCase is the correct way, and all we need to do is annotate it with SWTBotJunit4ClassRunner. Later we could look at how to use the launcherrunner to run the application under test, but that should be a trivial change after this one.
Created attachment 124368 [details] Migrates to JUnit 4 for tests which extend TestCase directly In this patch I migrated the tests which extend directly TestCase (except of course SWTBotTest, which must not be changed for compatibility with JUnit 3 tests out there). There is a new class SWTBotAssert which I made out of SWTBotTestCase. It is similiar to the new junit.framework.Assert class. The advantage of it is that one does not need to extend unit.framework.TestCase anymore in order to write JUnit 4 tests. The hierarchy of the own test classes is free to be used in order to subclass something else. I didn't use @RunWith when migrating the SWTBot tests which direcly subclass TestCase, because BlockJUnit4ClassRunner is used anyway by default I think. And if the runner class changes in JUnit (as it did previously), then no maintainance in a lot of test classes is necessary. Or we could run it with a dummy SWTBot runner, so that maintainence would be just in one class, if necessary one day. The test case names are in JUnit 4 style with no "test" prefix anymore. I also removed unneeded "throws Exception" declarations by the way and added generics for collections here and there, for example instead of "List widgets" -> "List<Widget> widgets". Cosmetic stuff because of compiler warnings. Suites have also been migrated, but not all, just the ones releated to the tests which I migrated. I had problems applying the patch. The "Guess" button needs to be pressed before applying, then it works. Thats just a trivial part of course of the migration. But it lets me see if its on the right track with how you imagine it to be.
Seems rather stupid for me to ask this, but are you able to run the plugin tests from within the IDE ?
In the past I started SWTBot plugin tests in the Eclipse IDE and it worked. Of course the SWTBot launcher plugin must be installed in the IDE's install location. I tried to build SWTBot now and install it (to try this), but it failed because it expects a "unzip" executable which I don't have. So I can't tell you for sure if it works currently too.
(In reply to comment #10) > I tried to build SWTBot now and install it (to try this), but it failed because > it expects a "unzip" executable which I don't have. So I can't tell you for > sure if it works currently too. You can get unzip from http://www.info-zip.org/UnZip.html#Downloads
I could build it now (after installing unzip and svn on my home PC) and installed the SWTBot plugins. I tried to run "org.eclipse.swtbot.eclipse.ui.test" plugin as "SWTBot Test" with option Test runner="JUnit 4"). Thats the migrated classes from me, so it should work. When the test run it started a workbench, but then it said: java.lang.Exception: No runnable methods at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:33) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.swtbot.eclipse.core.RemotePluginTestRunner.main(RemotePluginTestRunner.java:63) at org.eclipse.swtbot.eclipse.core.UITestApplication.runTests(UITestApplication.java:122) at org.eclipse.ui.internal.testing.WorkbenchTestable$1.run(WorkbenchTestable.java:68) at java.lang.Thread.run(Thread.java:619) When I run it on the unmodified SWTBot version (trunk-head) and started it as a plugin-test with option JUnit 3 test runner, then this exception was thrown: Exception in thread "WorkbenchTestable" java.lang.ClassCastException: junit.framework.TestSuite cannot be cast to junit.framework.Test at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.getTest(JUnit3TestLoader.java:108) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestLoader.loadTests(JUnit3TestLoader.java:59) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:445) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.swtbot.eclipse.core.RemotePluginTestRunner.main(RemotePluginTestRunner.java:63) at org.eclipse.swtbot.eclipse.core.UITestApplication.runTests(UITestApplication.java:122) at org.eclipse.ui.internal.testing.WorkbenchTestable$1.run(WorkbenchTestable.java:68) at java.lang.Thread.run(Thread.java:619) As it seems its broken currently. I din't analyse this yet on both sides.
@Ketan Padegaonkar Are these the only plugin tests in SWTBot? - org.eclipse.swtbot.eclipse.finder.AllTests - org.eclipse.swtbot.eclipse.ui.test.AllTests How do we go on now with migration? Can you already integrate the patch I attached? Are you investigating why the plugin-tests can't be run from within IDE anymore?
(In reply to comment #13) > @Ketan Padegaonkar > > Are these the only plugin tests in SWTBot? > > - org.eclipse.swtbot.eclipse.finder.AllTests > - org.eclipse.swtbot.eclipse.ui.test.AllTests These are the only plugin tests that need migration, the rest of them are plain tests, so your patch seems fine. On preliminary investigation it seems to be an issue caused because of junit4.5, as jdt only supports upto junit4.4, I might have to create a compatibility plugin as the other Ketan recommended on the mailing list :(
I encountered same problem as Comment #12, add me to cc list
I've fixed the issue mentioned in comment #12. I'm marking this as fixed. Hans/Hugulas, can you verify and mark as closed ?
Milestone set to 2.0
