Getting started with the TCK might be a little daunting, so here are a few lines that might be of help -
There is a readme available in the ../pluto/portlet-tck_3.0 directory that describes overall structure and basic TCK setup. Beyond the readme, I don't have any documentation about the TCK. I know it would be good to have it, but there is a lot to do, so it will take a while before I get around to that. In the interim, here are a few notes that I hope will be helpful. The TCK consists of portlets containing the actual test code along with a Selenium-based test driver that causes all of the test cases to be executed. The selenium code just acts as a data collector to address each test and collect the results. The selenium code is just a single (pretty big - 6k entries) parameterized Junit test case. The collection returned by the Junit @Parameters function is generated from the \portlet-tck_3.0 \driver\target\classes\generated-resources\xml\final\test.xml file, which is basically the XML form of a Java Properties file. The key in that file is the test case name, and the value is the page name on which the TC is located. This test.xml file is generated during the build process basically by concatenating the test case list from each individual module. For most of the existing modules, the test case list is equal to the "additionalTCs.xml" file. The fields within the test case name that are separated by underscores was my means for assuring that the test case names remain unique over the whole TCK. They are related to fields within the TCK assertions document located in: \portlet-tck_3.0\src\main\javadoc \doc-files. The driver processes each test case (= key in the props file) in a fixed manner. It's a little complicated in detail in order to try to achieve better performance, but boiled down to its essence, it's like this for each test case: 1) Access the page on which the TC is located 2) check for a "setup" link or button for the TC. If available, click it & wait for page to load 3) check for an "action" link or button. If available, click it & wait for page to load (Note that "action" here is somewhat of a misnomer - it does not have to be a link resulting in a portlet action request. It can be a render URL as well). 4) By now at the latest, test results should be available, so get the results (success or failure) along with the details string and assert based the results The selenium code locates the results, details, links, and buttons artifacts on the page based on the HTML ID and NAME attributes. The (optional) "setup" link can be used for setting up preconditions such as private / public parameters before the test. The (also optional) "action" link executes test case itself. For example, you could use this mechanism to set a parameter as precondition, then during the "action" part of the test delete the parameter, and during the result phase verify that the parameter is really gone. But for many tests, such as whether an null value in a method argument will cause an exception, you don't really need a setup or an execution link. For tests like this, you can just do the test and render the result. Some flags understood by the driver: -Dtest.timeout=<# of seconds> - timeout that the driver uses when waiting for a page to load. Default is 3 seconds. I find it useful to set this to 1. -Dtest.debug=<true> - causes the driver to be very verbose. Only useful when executing a small number of test cases. -Dtest.module=<String> - causes the driver to execute only those test cases whose name contains the specified string. Good for debugging a test case or set of test cases. Some example test command strings: (Hint: before running the tests, switch to the ../pluto/portlet-tck_3.0/driver directory - makes the output somewhat clearer) // run all defined tests in all modules: mvn test -Prun-tck // run all tests in the V2URLTests module: mvn test -Prun-tck -Dtest.timeout=1 -Dtest.module=V2URLTests // run all tests across all modules whose name contains the string "setParameter" mvn test -Prun-tck -Dtest.timeout=1 -Dtest.module=setParameter // run a single test case with timeout set to 1 sec in debug mode: mvn test -Prun-tck -Dtest.timeout=1 -Dtest.debug=true -Dtest.module=V2URLTests_BaseURL_ApiRenderRenurl_setParameters6 It turns out that the test case in this last example uses a setup link, an "action" link, and then renders the results, so if you want to look at a full-blown test case as an example, this one might not be a bad pick. The code is contained in the V2URLTests_BaseURL_ApiRenderRenurl.java class within the V2URLTests module. Just search for the test case name "V2URLTests_BaseURL_ApiRenderRenurl_setParameters6". In the common module, there are some potentially useful helper classes: TestLink - generates an "action" link understood by the driver for the input RenderURL (GET) TestButton - generates an "action" link understood by the driver for the input ActionURL (POST) TestSetupLink - generates a "setup" link understood by the driver for the input RenderURL (Haven't run into need for a setup button, but it would be easy to make if necessary) TestResourceLink - generates an "action" link understood by the driver for the input ResourceURL. It includes JavaScript in the markup for carrying out the resource request when the link is clicked. TestResult - generates markup for test results and details in a manner that can be understood by the driver CompareUtils - Contains some comparison routines for arrays, maps, etc that update an input TestResult according to the results of the comparison Also, the generated skeleton portlet code contains a mechanism that allows test results generated in the Action, Event, or Resource phases to be transported to the Render phase for rendering. I think this mechanism will be sufficient for most uses, but you may encounter a situation where that won't suffice, in which case, you'll have to write your own, I guess ... :-) . So that was an overview in a nutshell ... hope it's useful. regards, Scott
