Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Touchstone - Unit Testing Framework for Portlets

IP.com Disclosure Number: IPCOM000019481D
Original Publication Date: 2003-Sep-16
Included in the Prior Art Database: 2003-Sep-16
Document File: 3 page(s) / 12K

Publishing Venue

IBM

Abstract

Disclosed is design of a framework for unit testing portal applications (portlets). The framework allows portlet developers to unit test at the class and/or method level any portlets designed to work within the same API as the provided framework. Using commonly available tools such as JUnit, a development process can be created that takes advantage of the framework to ensure that portlets perform as expected and continue to perform the required functionalty during code changes or refactoring.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

Touchstone - Unit Testing Framework for Portlets

  This document outlines the development of a unit testing framework for portal applications. The framework allows portlet developers to unit test at the class and/or method level any portlets designed to work within the same API as the provided framework. Using commonly available tools such as JUnit, a development process can be created that takes advantage of the framework to ensure that portlets perform as expected and continue to perform the required functionality during code changes or refactoring.

Framework Core

The core of the framework is the creation of a set of Mock Objects that can be used by the portlet similar to objects available within the portlet container. This set of classes and objects is essentially a set of lite classes that can be created, passed to, and used by the portlet. After a portlet method has run the testing class can inspect the objects to determine if the correct information was set by a portlet method based on calling parameters. In essence the framework provides the same API as is available within the portal itself. This mapping of methods within a similar package and class structure is what gives the structure its power. The ability to control the instanctiation and manipulation of the mock container allows testing at a very fine grained level.

Test Classes

Test class can be developer created classes that exercise a portlet, or they can be derived from the popular JUnit testing framework. Using JUnit tests can be created using a standard approach and results can be provided in a well defined manner. A simple example of how a test method might be created is as follows:

public void testDoView() throws Exception {

// create the objects needed by the portlet or method under test.

PortletConfig portletConfig = new PortletConfigMock();

PortletRequest portletRequest = new PortletRequestMock();

PortletResponse portletResponse = new PortletResponseMock();

// create an instance of the portlet and run the test.

              SampleCrudPortletController controller = new SampleCrudPortletController();

controller.init(portletConfig);

controller.doView(portletRequest, portletResponse);

// check the resulting objects to ensure the portlet performed the correct

operation.

// here the bean is pulled out of the request but not checked (example only).

              SampleCrudPortletBean resultBean = (SampleCrudPortletBean)portletRequest.getAttribute("MyControllerBean");

1

P...