David,
I am unsure why this would happen, but I wanted to report it in case
anyone else hits this problem or has a clue as to why it's happening.
I updated my target platform to the latest M4 build, including the
updated eclipse platform build (my dev environment is Eclipse 3.5.1).
I tried to run my tests (still using junit3) and received a CCE:
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:452)
An obviously weird CCE that doesn't make sense. I started poking
around my target platform and realized the the eclipse platform zip
includes two JUnit4 plugin folders:
org.junit_4.7.0.v20091118-1515
org.junit4_4.7.0.v20091207
I deleted the first one (since it didn't match the naming from the last
platform build) from the plugins folder and then reran my tests and
they worked fine. Any ideas?
Thanks,
Karen
On 11/30/2009 10:47 PM, David M Williams wrote:
Good new and bad news: JUnit 4 is now supported by
the Eclipse test framework,
but JUnit 3 no longer is. Well, mostly no longer
is.
So, we'll have to change
some things.
The referenced write up is pretty good at
describing
what we'd have to do to migrate to JUnit 4.
http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes
Which I'd summarize as:
A. Widen or raise org.junit prereq bundle version
ranges.
We should use the recommended, open-ended "3.8"
until you know you are using something that is 4.x specific.
B. Subclasses of TestSuite that override 'tests()'
have some work to do. From what I can see,
from what's in my workspace, that involves only
the
server team, and these bundles below.
I _think_ the fix is easy ... but ... someone
would
have to study it and do it and _maybe_
coordinate when to release the code (can probably
be changed in a compatible way, so runs
with either, but I'm not certain).
org.eclipse.jst.server.core.tests
org.eclipse.jst.server.tomcat.core.tests
org.eclipse.jst.server.tomcat.ui.tests
org.eclipse.jst.server.ui.tests
org.eclipse.wst.internet.monitor.core.tests
org.eclipse.wst.internet.monitor.ui.tests
org.eclipse.wst.server.core.tests
org.eclipse.wst.server.http.core.tests
org.eclipse.wst.server.ui.tests
C. Custom subclasses of
junit.framework.TestResult.
The JUnit class TestResult changed several of its protected fields from
Vector to List.
The following list are those bundles I could
easily
see that subclassed TestResult. Not all
of them use the Vector fields ... but many do. You'll have to check
your
own. Appears to
involve many teams. I'm less sure this can be done
in a compatible way ... may need to
time the release ... but, maybe. Please
investigate.
Maybe you can do without the subclass
or field access?
org.eclipse.jpt.utility.tests.internalr
org.eclipse.jst.jsf.test.util
org.eclipse.jst.validation.test.junit
org.eclipse.jst.ws.tests.unittest
org.eclipse.wst.common.extras
org.eclipse.wst.common.tests.performance.internal
org.eclipse.wst.jsdt.core.tests.junit.extension
org.eclipse.wst.jsdt.core.tests.model
org.eclipse.wst.jsdt.core.tests.util
org.eclipse.wst.ws.tests.unittest
D. I'm sure there's stuff not in my
workspace, so every component or subproject will need to investigate
and
test in their workspace.
Until we move up to new test
framework,
you can get a copy of JUnit 4 directly from Orbit.
http://download.eclipse.org/tools/orbit/downloads/drops/I20091124014054/bundles/org.junit_4.7.0.v20091118-1515.zip
So what to do about it? We will
discuss
and decide at our next Status meeting on Thursday.
Roughly, the options are:
1. Full speed ahead, be assimilated,
migrate as soon as possible.
2.. Go slow and custom tweak our
test
environment so it'd have only JUnit 3 for those tests that do not want
to change, and JUnit 4 for those that do want to change.
3. Some bright person figures out a
way we can have our own Test Framework that works just like we want it
to. Any volunteers? :)
So, give it some study. Give it some
thought. We'll discuss and decide on Thursday.
If or when you find things you have
to change, I recommend you open a bug with "React to JUnit 4 Test
Framework" in the summary and CC me, so I'll know when we are done
and safe to update to new pre-reqs, assuming we do.
----- Forwarded by
David
M Williams/Raleigh/IBM on 11/27/2009 10:48 PM -----
If you are using the Eclipse platform's test framework for running your
automated JUnit tests, please read on for important details about
changes
coming in the Helios M4 milestone.
The Eclipse test framework has had a long-standing request to add
support
for running with JUnit version 4. See bug 153429 with 40 votes and 75
people
on the CC list to get an idea of the interest in this change. After a
great
deal of work by the JDT, Platform Releng, and Equinox teams, this
support
is coming in the Helios release. Unfortunately it was not possible to
implement
this enhancement in a completely transparent way for clients of the
Eclipse
test framework. For most clients migration to JUnit4 will be as simple
as changing your test bundles' dependency on org.junit to include JUnit
4.x in its version range. We are recommending setting your dependency
on
org.junit to a range of "3.8.1", which encompasses all versions
of JUnit shipped by the platform since the Callisto (June 2006) release.
For complete details on the steps required to transition to using
JUnit4
or to continue using JUnit3, please see:
http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes
Comments and further feedback are welcome in the bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=153429
John _______________________________________________
eclipse.org-committers mailing list
eclipse.org-committers@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-committers
IMPORTANT: Membership in this list is generated by processes internal
to
the Eclipse Foundation. To be permanently removed from this list,
you must contact emo@xxxxxxxxxxx to request removal.
_______________________________________________
wtp-releng mailing list
wtp-releng@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-releng
|