talk. - ACET

cabbagepatchtapeInternet and Web Development

Feb 5, 2013 (4 years and 2 months ago)

115 views

Portal Software Unit Testing


Supporting agile development of

Sakai VRE enhancements

Graham Klyne

Oxford University Computing Service

<graham.klyne@oucs.ox.ac.uk>

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

Non
-
goals


User interface/presentation testing


System integration testing


Full
-
system acceptance testing

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

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


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

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


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

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

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

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
APIs


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


maybe Aspects could be used to simplify Java APIs?

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