To answer your problem first, if you have a discrepancy between Ant junit and Eclipse JUnit, this is probably a class problem or environmental issue. The easiest way is to find a test that runs in different ways between them and print the properties of the system, and work with it from this direction. Another thing is to try to run Ant scripts from Eclipse to make sure that it matters (as the environment will change)
Eclipse does not use Ant to run tests.
As for how Eclipse runs JUnit tests, here is a quick overview. Be careful: the Eclipse JUnit plugin has some deep magic.
Eclipse has 4 JUnit plugins that are installed by default in most configurations:
- org.eclipse.jdt.junit: git: //dev.eclipse.org/org.eclipse.jdt/org.eclipse.jdt.junit.git
- org.eclipse.jdt.junit.core: git: //dev.eclipse.org/org.eclipse.jdt/org.eclipse.jdt.junit.core.git
- org.eclipse.jdt.junit.runtime: git: //dev.eclipse.org/org.eclipse.jdt/org.eclipse.jdt.junit.runtime.git
- org.eclipse.jdt.junit4.runtime: git: //dev.eclipse.org/org.eclipse.jdt/org.eclipse.jdt.junit4.runtime.git
This is a git mirror of the actual CVS repositories. The last time I tried to use them, they did not compile, but they will give you the code, and you can at least import projects into Eclipse and look at them.
If we ignore the configuration pages, how the plugin creates launch configurations, the code for the JUnit view itself, and how it finds the appropriate tests to run, we can focus on how it runs the tests.
The key classes are org.eclipse.jdt.junit.launcher.JUnitLaunchConfigurationDelegate and org.eclipse.jdt.internal.junit.runner.RemoteTestRunner . JUnitLaunchConfigurationDelegate reads the startup configuration and expands the JVM in which the tests will be run. The main class for this new JVM is RemoteTestRunner . Those tests that must be run are passed as parameters for the forked JVM, either as a single test, or as a list of tests in a temporary file if you run Run as JUnit in a project. If you are debugging, this new JVM can be saved by checking the Keep alive when debugging checkbox in the launch configuration. In this case, the JVM will stick, and retries of existing tests will be sent via sockets.
RemoteTestRunner runs the tests and passes the results through sockets to Eclipse, which then updates the JUnit view. The heart of this is org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference , which runs the test (for JUnit 4) and org.eclipse.jdt.internal.junit4.runner.JUnit4TestListener , which is the RunListener for these tests. JUnit4TestListener extends RunListener , but does not override testAssumptionFailure , which is probably due to the fact that your tests pass in Eclipse. RunListener.testAssumptionFailure is an empty method, it does nothing, so your notifications will be ignored.
I would start cloning git repositories by importing projects into Eclipse and trying to work through code.