I completed all of the dispatcher tests that I thought could be generated
from the spec assertions file. I organized it so that the remaining
dispatcher tests that could not be generated automatically are located in
separate modules. The two modules containing the remaining unimplemented
dispatcher tests are: "V2DispatcherTests3S" and
"V2DispatcherReqRespTests5S". The other dispatcher modules are completely
implemented I believe.
As already noted, the TCK dispatcher tests show several problems that I
believe to be bugs in Pluto. I'll describe the problems in the Pluto JIRA
as soon as I get around to it. The unimplemented tests contained in
"V2DispatcherTests3S" (along with quite a few tests in module
V2DispatcherTests5) are blocked by these problems, so it probably wouldn't
make a lot of sense to implement those test cases with high priority.
I also redid the portlet tag library tests and the additional spec tests
(contained in the modules whose names carry the string "Addl") to put the
test cases in the right method and also to generate the test case names in
a consistent manner. The test case names for the additional spec tests, the
portlet tag library tests, and the dispatcher tests now all have the
following structure:
Test Case Name
==========================================================
Portlet Name
===============================================
Module chptr/cls keywords test name
================= ======== ==================== ===========
V2DispatcherTests_SPEC2_19_IncludeServletRender_attributes6
V2AddlPortletTests_SPEC2_5_ActionHandling_exception2
where "chptr/cls" represents the spec chapter containing the assertion for
the additional spec tests, or the JSR 286 API class description containing
the test assertion for the apidoc tests. This allows a failing test case to
be easily localized, which might be important considering the fairly large
number of tests that we have / will have.
When test cases are added that are defined by hand, we don't necessarily
have to adhere to this scheme, although I think it would be a good idea.
I am going to redo the apidoc tests to adhere to this scheme as well. Hope
to be done with that work in a couple of days.
Mit freundlichen Grüßen, / Kind regards,
Scott Nicklous
WebSphere Portal Standardization Lead & Technology Consultant
Specification Lead, JSR 362 Portlet Specification 3.0
IBM Software Group, Application Integration Middleware
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294