portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Scott Nicklous <Scott.Nickl...@de.ibm.com>
Subject Test Framework update
Date Fri, 27 Jun 2014 13:54:35 GMT

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

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.


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.



View raw message