Version 3

    Description

     

    The portlet container testing framework relies on a set of artifacts :

     

    1. a servlet filter present in front of the portal : TestContextFilter

    2. in each portlet test case a special portlet : TestCoordinatorPortlet

    3. on each request to the portal, a test id and a test count

     

    A test case is initiated by the client (the junit test) and is based on a specific protocol. The protocol will probably need to be extended in the future when we'll complete the test cases.

     

    Example of interaction we have :

     

    1. client deploys the portlet application war file and blocks until it is done

    2. the portal deploys the war file, some portlet start up and register against the coordinator portlet

    3. the deployment is done, the client can continue

    4. the client calls the test coordinator portlet which returns it a list of all the portlet that can initiate tests in the portal

    5. the client iterates on each test

      1. the client initiates a test with its id and its counter equals to 0 by invoking the portal

      2. the portlet recognize its id and use the counter to send a result back to the client

      3. the client receive the result and react to it based on the protocol

      4. at one point the test will terminate

     

    Example

     

    Now it is probably a good idea to explain an example : we test that a portlet action url creates the right parameters and can be retrieved from the process action.

     

    1. the client deploys the portlet application war file

      1. the portal creates the TestCoordinatorPortlet

      2. the portal creates the RequestParameterPortlet which register itself against the TestCoordinator through a static call

    2. the client initiates the test

      1. it makes a render request to the portal with a special id that only the TestCoordinatorPortlet recognize

      2. the TCP returns a TestCoordinatorResult containing the id of the test to execute which is equals to RequestParameterPortlet

    3. the client do the test of RequestParameterPortlet

      1. the client makes a render request to the portal with id=RequestParameterPortlet and count=0

      2. the portal renders all the portlets and only the RequestParameterPortlet returns a result that contains an InvokerURLResult with an action PortletURL that setup parameters foo1=bar1 and foo2=bar2_1,bar2_2

      3. the client retrieves the InvokeURLResult and reacts to it by invoking the url is asking to

      4. the portal receives the request and process action of the RequestParameterPortlet portlet

      5. during the action the portlet creates an AssertResult that makes a set of junit assertions and then set the AssertResult as a field of the portlet

      6. the portal then executes the render phase and the portlet just send the AssertResult back to the client

      7. the client receives the AssertResult and reassert it making eventually a portlet issue appear on the client and then terminates the test

    4. the clients undeployes the portlet application war file

     

    The different kind of responses from a request to the portal

     

    • 404 not found

    • 302 redirect

    • an HTML response containing RenderResult

     

    Protocol description

     

    • 302 : execute the redirect

    • 404 : terminates the test

      • FailureResult : fails on the client with the server side stack trace

      • EndResult : terminates the test

      • AssertResult : reassert a server side assertion and terminates the test

      • InvokeURLResult : reinvoke the url provided