talk. - ACET

cabbagepatchtapeInternet and Web Development

Feb 5, 2013 (5 years and 3 months ago)


Portal Software Unit Testing

Supporting agile development of

Sakai VRE enhancements

Graham Klyne

Oxford University Computing Service



Construct a framework for testing Shibboleth
“token” passing in WSRP

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


User interface/presentation testing

System integration testing

system acceptance testing

Some options considered (1)


very complex framework for testing purposes

fragile: very sensitive to software versions used


replaces portlet container, which is part of environment
to be tested


uses HTTP protocol; requires complex test environment
including servlet engine; “plan B” fallback option

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

Components selected


“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


for access to remote portlets via WSRP

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

Progress so far

Dec 2005, one person, part

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


look at WSRP testing with WSRP4J

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

ServletUnit uses older versions of ServletAPI,
Pluto requires some newer features

ServletUnit works well within the Eclipse IDE

Observations (2)

ServletUnit needs some extension to handle
URI/context directory matching and cross
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

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

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.

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

configuration of simple deployments can be eased by
sensible use of overridable default values

maybe Aspects could be used to simplify Java APIs?


Servlet API specification (JSR

Portlet API specification (JSR


OASIS TC page, links to specification:


Apache Pluto project:

HttpUnit project:

JUnit home page:



uPortal/WSRP setup notes:



Pluto installation/testing details, wiki notes: