I received feedback on the test framework that it would fit in easier with different portal URL generation strategies if the test driver would follow links generated by the portal rather than generate its own test URLs. To accommodate this, I made some changes to the test framework:
* Added "test.server.login.url" property to specify the initial portal page * Added "test.url.strategy" property that allows selection of whether tests are executed through URLs generated by the driver or through links generated by the portal * Implemented the corresponding functionality by changing code in several modules If the TCK driver is set up to follow links produced by the system under test, then the SUT must produce navigation links to the pages for each test case on all pages. When following the links to the test pages, the driver looks for link text equal to the page name taken from the "tests.xml" properties file, so the SUT is free to generate the links in any required form as long as the link text equals the test page name. See: https://github.com/msnicklous/portletspec3/tree/master/portlet-tck_3.0 Also, I added API documentation creation to the TCK POM. The API documentation and Surefire reports for the tests (which are not in a very good form yet) can be generated using "mvn site". Finally, I began work on a TCK test assertion document. The assertions are derived from the JSR 286 specification and API documentation. The TCK will eventually implement the tests described in the assertions document. The assertions document is organized into tables according to the source of the assertion. Each row in the table describes a single assertion. To allow for the situation that some assertions may not be testable, each assertion also has a "Test" flag which is set to "true" if the assertion can be tested by the TCK and "false" if it cannot. Initially I will set the flag to "true" unless it is absolutely clear that an assertion cannot be tested, so it may turn out that during the TCK implementation, additional assertions will need to be marked as untestable. The initial goal will be to document test assertions for the JSR 286 backward compatibility testing. The document will later be expanded to document assertions for new and changed JSR 362 functionality. The initial version documents just a few tests to try out the format. I took a fine-grained approach to describing the assertions in order to reduce the possiblity of misinterpretation during test case implementation, so we will probably end up with quite a few of them. Please have a look and let me know if anything should be changed. I will be working on the assertions document as much as possible, concentrating on the API assertions initially, and will post updates regularly. I hesitate to estimate when I'll finish with the JSR 286 compatibility assertions due to my vacation, but I hope to have a reasonable start documented by Monday. See: https://github.com/msnicklous/portletspec3/blob/master/portlet-tck_3.0/src/main/javadoc/doc-files/JSR362Assertions.pdf regards, Scott
