Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.0.1-rc4, 1.1.0-alpha1
-
None
Description
I checked the source of testsuite: It uses the command pattern to execute tests. Here are some suggestions, as well as a bug report:
Suggestions:
1. To move some testsuite-framework-related classes from package org.apache.pluto.testsuite.test to package org.apache.pluto.testsuite, to make the testsuite framework completely independent of the concrete test package. These class includes:
- TestResult
- TestResults
- PortletTest
- ActionTest
- NoOpTest
2. Make the TestConfigFactory singleton, and provide a static getFactory() method. Rename its method createTests() to createTestConfigs(), because in fact this method parses the config file and returns a list of TestConfig instances, but not tests.
3. Add a "PLT" attribute to the TestConfig class to indicate which part of the portlet spec is tested by which test class. So that we may know how the spec is covered by the testsuite.
A bug report: this bug is in fact caused by the portlet session binding issue: When executing the "Simple Action Parameter Test", the test results are displayed in a wrong way. The reason is:
The simple action parameter test is an ActionTest, so it is executed in TestPortlet.processAction(), and results are saved in the portlet session. But because of the binding issue, TestPortlet.render() failed to retrieve the results from portlet session. So when dispatching to the /jsp/test_results.jsp, there are nothing in the session. The file /jsp/test_results.inc uses JSTL to retrieve the results. EL Expressions like:
<c:when test="${results.failed}">
will always pass as if ${results.failed} returns false, if JSTL can't find attribute value for the "results" key. So, even the JSP failed to get the results from session, we still got a PASSED page.
I am also thinking about adding more tests to the testsuite subproject.
ZHENG Zhong