1. Portal Software Unit Testing Supporting agile development of Sakai VRE enhancements Graham Klyne Oxford University Computing Service

2. Goals Construct a framework for testing Shibboleth “token” passing in WSRP Easy-to-repeat tests –following agile programming practices –run tests as a JUnit test suite Runnable in Eclipse debugger –for visibility of dynamic code behaviour Minimize new software coding –use existing frameworks

3. Non-goals User interface/presentation testing System integration testing Full-system acceptance testing

4. Some options considered (1) uPortal –very complex framework for testing purposes –fragile: very sensitive to software versions used PortletUnit –replaces portlet container, which is part of environment to be tested HttpUnit –uses HTTP protocol; requires complex test environment including servlet engine; “plan B” fallback option

5. Some options considered (2) Mock object frameworks –e.g. Jmock, MockRunner –promising idea, but for present purposes these leave too much supporting test logic to be implemented

6. Components selected ServletUnit –“mock” servlet engine, part of HttpUnit framework –test cases call directly into servlet code Pluto 1.1 –portlet container –simple portal driver (servlet) –test portlets WSRP4J –for access to remote portlets via WSRP

7. The Cunning Plan The existing Pluto test framework under Tomcat provides a browser-driven reference environment Create a ServletUnit test environment to drive the Pluto test framework as an automated test suite Extend automated test environment to drive Pluto test portlets via WSRP Extend to test Shibboleth token passing Retain HttpUnit as a fallback position –most of the test driver code is the same

8. Progress so far Sep-Dec 2005, one person, part-time Initial explorations (uPortal, WSRP, test frameworks, development tools, etc.) Pluto 1.02 interactive tests run under Tomcat Pluto 1.1 interactive tests run under Tomcat Have run most tests in an automated test environment using a previous Pluto code revision New Pluto code revision breaks the test setup Next: look at WSRP testing with WSRP4J

9. Observations (1) Pluto is not as lightweight as it claims to be –the learning curve is rather steep –configuration is complex and hard to understand Pluto 1.1 is a moving target Pluto’s own unit test coverage is limited Problems with Tomcat 5.5-12 (am using 5.5-9) ServletUnit uses older versions of ServletAPI, Pluto requires some newer features ServletUnit works well within the Eclipse IDE

10. Observations (2) ServletUnit needs some extension to handle URI/context directory matching and cross-context features of Pluto –a “mock servlet engine” is a complex piece of code, which has to handle many details HttpUnit facilities for testing responses are quite flexible and easy to learn –can get more complex when dealing with complex HTML responses, as generated by portal/portlet code

11. Conclusions (1) The Java portal framework is not easy to use –complex, fragile, excess of “magic” –does not easily support “agile” projects –lacks a readily-grasped “big picture” to make sense of the mass of details –many components are tightly coupled by complex APIs

12. Conclusions (2) Unit testing of servlets holds much promise –the servlet test environment is inherently complex and needs to be well supported, particularly with respect to tracking changes in the servlet API Servlet testing is not well thought out –complex APIs and hidden internal communication paths make it difficult to observe and modify component interactions –servlet code is highly committed to the servlet API, making it difficult to isolate for testing.

13. Conclusions (3) Comparison with “agile” web frameworks –e.g. Ruby/Rails, Python/Turbogears, Java/Spring –lightweight, loosely-coupled application frameworks make it easier to test pieces in isolation, and make the component coupling more visible and easier to control –many lightweight frameworks use functional programming idioms to simplify many of the complex APIs –configuration of simple deployments can be eased by sensible use of overridable default values –maybe Aspects could be used to simplify Java APIs?

14. References Servlet API specification (JSR-154): http://jcp.org/aboutJava/communityprocess/final/jsr154/ Portlet API specification (JSR-168): http://jcp.org/aboutJava/communityprocess/final/jsr168/ WSRP - OASIS TC page, links to specification: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp Apache Pluto project: http://portals.apache.org/pluto/ HttpUnit project: http://httpunit.sourceforge.net/ JUnit home page: http://www.junit.org/index.htm WSRP4J: http://portals.apache.org/wsrp4j/ uPortal: http://www.uportal.org/ uPortal/WSRP setup notes: http://www.oucs.ox.ac.uk/portal/developers/environment.xml Jmock: http://www.jmock.org/ MockRunner: http://mockrunner.sourceforge.net/ Pluto installation/testing details, wiki notes: http://wiki.oss-watch.ac.uk/PlutoNotes