[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-jst-dev] RE: Contributing new JEE project facets
|
Hello,
I examined the org.eclipse.jst.j2ee.core.tests packages. I
concentrated mainly on the tests that are started by the automated test system
[1].
I found just few tests (at least for now) that have to be
modified to check JEE 5 functionality.
I created bug 152128 [2] that holds the patch and short
description.
I also checked other tests in this package that are not
executed by the automated test system. I am still wondering why they are not
executed. This confuses me if I have to look at them at all. One example is the
org.eclipse.jst.j2ee.ejb.test.EJBJarTest which even fails on the test_getVersion() and
test_getJ2EEVersion() tests.
I am going to continue with the org.eclipse.jst.j2ee.tests
package where seems to have a lot of more to be
modified.
Hi,
> Not sure. But, how are you
"counting" the tests? I did a java search for all declared methods that started
with "test*" and it was in the hundreds, not 1300, with that project selected.
If I
checkout the org.eclipse.jst.j2ee.core.tests plugin from the CVS and execute
'Run As -> JUnit Plug-in Test' then it starts all tests defined in the
plugin. The exact number is 1349 placed in many groups (see the attachement).
This contrasts with the 287 displayed in official Unit Tests Results for this
test plugin [1]. Actually only 2 groups of the test in the plugin are executed.
My question why the others are not - it just looks strange.
> First, I'd
suggest is to have your own machine set up to do some tests, and be sure to
check all the current tests (even from other comonentets, such as web services)
all pass before and after your proposed patches.
Currently, I run the tests manually from the Eclipse IDE. We are working
on setting up a system with Automated Test Framework and define set of test
groups to be executed automatically.
Thank
you for the guidelines. We will start with modifying existing tests with JEE 5
specific checks.
Greetings
Kaloyan
I have had a look at some documents regarding Automated testing and the
org.eclipse.jst.j2ee.core.tests and org.eclipse.jst.j2ee.tests plugins.
I noticed something strange. Let's
take the org.eclipse.jst.j2ee.core.tests plugin. There are ~1300 tests defined
there, but only ~300 are executed on the central test system [2]. Why is this?
What about the other ~1000 tests?
Not sure. But, how are you "counting" the tests? I did a java
search for all declared methods that started with "test*" and it was in the
hundreds, not 1300, with that project selected. Another question is where can I see something like method
coverage of the current tests? I don't think its updated for each build, but you can reference
those from the released build. http://download3.eclipse.org/webtools/downloads/drops/R1.5/R-1.5.0-200606281455/apiresults/full_test_coverage/api-tc-summary.html
We use TPTP to generate these. Cameron Batemon wrote up a
short note pointing to how to get started using this feature of TPTP on the jsf
newsgroup: http://dev.eclipse.org/mhonarc/lists/wtp-jsf-dev/msg00120.html
Can we have also some guidelines in
which direction to improve the test cases?
The most important thing is to get started! :)
But I'll just give some "general" advice. First, I'd suggest is to have your own machine set up to
do some tests, and be sure to check all the current tests (even from other
comonentets, such as web services) all pass before and after your proposed
patches. Second, you might slide
into "little" changes first, and simply find some existing test that "works" for
some J2EE 1.4 specific value or behavior, copy the test, change it to be J2EE 5
specific, and make sure it works as expected. You might also include a good set of "failure expected"
tests. What I mean is to find a J2EE 1.4 test, that has J2EE 1.4 "input", but
would be expected to fail if given J2EE 5 input. Then, write your JUnit to
"pass" if the code "fails" as expected (e.g. throughs a "not found, or "not
legal" exception). You could do this "both directions" if possible. (I don't
know that there all that many that would succeed in one case, but fail in the
other ... but, in my experience "testing for correct failure" is often
overlooked in unit testing. Remember
not all JUnits do not *have* to be big and complicated. For example, can
every null argument constructor be called? And return an object without
exceptions? Lastly, its a nice touch
if time is put into the tests so the failure messages are "meaningful". For
example, instead of instead of Assert.notNull(servletList); its
best to have something like Assert.notNull("serveletList should never be null", servletList);
(This allows "readers" of the test
results to get an idea of what's failing without reading the code.)
Hope this helps. I'm sure the J2EE teams
will have more detail. Thanks.
