Junit 4 supported?

[EclipseDev]

Is JUnit 4 supported? When I run a Junit plugin test with Junit4 as the Test Runner, I get an exception in the getUI() code:

java.lang.IllegalStateException: Display has not been initialized.
at com.windowtester.runtime.swt.internal.junit.ExecutionEnvironment.getDisplay(ExecutionEnvironment.java:68)
at com.windowtester.runtime.swt.internal.junit.ExecutionEnvironment.createUI(ExecutionEnvironment.java:92)
at com.windowtester.runtime.swt.internal.junit.ExecutionEnvironment.getUI(ExecutionEnvironment.java:80)
at com.windowtester.runtime.swt.internal.junit.SWTExecutionMonitor.getUI(SWTExecutionMonitor.java:232)
at com.windowtester.runtime.swt.internal.junit.SWTExecutionContext.getUI(SWTExecutionContext.java:36)
at com.windowtester.runtime.common.UITestCaseCommon.getUI(UITestCaseCommon.java:252)

I have added Junit4 as a dependency of my test plugin. But the generated code from the recorder still generates Junit 3 like code (without the @Test annotations, that I have added myself). Is there anything else to do to use Junit 4?

I am using the latest version of WindowTester 3.5.1 with Eclipse 3.3.1.1

Thanks

[Phil Quitslund]

We do not have first class JUnit4 Support.

One of the reasons for this is exactly the experience you're describing: while JUnit3 tests should run out of the box using the JUnit4 test runner, there are issues with the JUnit4 test runner shipped with Eclipse 3.3.

What kind of JUnit4 support do you need/desire? Do you want to write UI tests using annotations? Do you want your existing UI tests to run in suites with JUnit4 style tests? If you do want annotated UI tests, what benefits do you perceive?

We are actively investigating strategies for integrating with JUnit4, so your input is greatly appreciated.

Thanks!

[EclipseDev]

Hi,

I would like to run parameterized tests, Junit 4 offers a good support for parameterization, whereas in JUnit 3, you either end up:
- running the same test from a test suite in a loop (all the tests have then the same name of the method being run in a loop: you don't know from the names which one failed, and which one succeeded). The test suite code is also not quite standard, so you can pass your parameters when instantiating the test.
- have a loop in the test itself, but at the first failure the test fail, and stops running the subsequent tests for the remaining parameters.

I don't mind using annotations or not, but it seems annotations is the only way to use JUnit 4 (unless I missed something?), it is only the parameterized mechanism which is of interest to me in JUnit 4.

Thanks.

[Mac]

Maybe for the moment a solution could be to have test methods with the parameters in its name which call the actual test method like:

Code: Select all

public void testExample11Params()
{
    myTest(1,1,"Params");
}

public void testExample12Params()
{
    myTest(1,2,"Params");
}

public void testExample13Params()
{
    myTest(1,3,"Params");
}


What are the other features you mentioned by the way?

[Phil Quitslund]

Parameterizing tests is definitely a hot topic (something we've discussed since before JUnit4). In a pinch I think Mac's suggestion is a good one (and a technique we use internally). But let's step back and ask the general question of how we might support this (shelving JUnit4 for the moment). To seed the conversation, could you give some concrete examples of the kinds of things you'd want to parameterize? From there we can explore the merits of possible solutions.

Thanks!

[EclipseDev]

My use case is quite simple:

I have a directory with files in it. I would like to run a given UI test on each file (i.e. opening the file, performing some generic operations, etc...). So I can't manually hard-code that, since the list of files might change.

Thanks.

[Phil Quitslund]

Interesting.

Is it necessary/desirable to specify each of these as a separate test? As a short-term stop-gap, you could certainly iterate over each file within the test.

Code: Select all

public void testAllFiles() throws Exception {
  for (String fileName : files)
     doTestFile(fileName);
}

void doTestFile(String fileName) throws Exception {
  ...
}


If this doesn't cut it, let's go further!

[EclipseDev]

Yes, it's necessary. I forgot to mention we want the tests to run for all files, even if a few files fail. If we put everything in one test, the first failure will stop processing the remaining files. That's the problem

Thanks.

[Phil Quitslund]

Got it.

One approach would be to build a dynamic test suite. Below you will find something that you can use as a jumping off point. (It tests String values but you can easily modify it to suit you needs -- if you hit any snags, let me know!)

Code: Select all

public class DynamicSuiteSample {

   public static Test suite() {
      TestSuite suite = new TestSuite("sample.dynamic.suite");
      for (String string : getStringsToTest())
         suite.addTest(new StringTest(string));
      return suite;
   }
      
   public static class StringTest extends TestCase {
      private final String toTest;
      public StringTest(String toTest) {
         super("testNotNull");
         this.toTest = toTest;
      }
      
      public void testNotNull() throws Exception {
         assertNotNull(toTest);
      }      
   }
   
   public static String[] getStringsToTest() {
      //this would actually be dynamically generated
      return new String[]{"one", "two", null /* bang! */, "three"};
   }
}

Do note: as written, this implementation assumes you only have one test method in the class (here: "testNotNull"). The approach can easily be extended to support multiple tests by putting more logic in the Suite creation. If you need more pointers, just let me know!