Click Mock API

Click Mock provides a full Mock stack which allows you to test Controls and Pages without the need for a Servlet container such as Tomcat or Jetty.

See:
          Description

Packages
net.sf.click Provides a mock package for Click, enabling unit testing of Pages and Controls.
net.sf.click.servlet Provides mock implementations of the Servlet API interfaces.

 

Click Mock provides a full Mock stack which allows you to test Controls and Pages without the need for a Servlet container such as Tomcat or Jetty.

The mock package is distributed as a separate jar and is available in the Click distribution you downloaded. Look under the dist folder for a jar called click-mock-<version>.jar.

For testing purposes there are two classes of interest: MockContainer and MockContext.


MockContainer

If you want to test your pages (functional tests) use MockContainer which simulates a servlet container such as Tomcat or Jetty. With the container you can mock page requests, form submissions, file uploads, navigation etc.

In order to use MockContainer you need to specify a web directory where the container can find resources such as javascript, stylesheets and images. The easiest way to achieve this is to point the container to your project's web directory.

For example if your project available in the directory c:\dev\myproject, and web resources are available under c:\dev\myproject\web, then simply point MockContainer to the directory c:\dev\myproject\web.

For example: (JUnit is used in these examples)

public class IntegrationTest extends TestCase {  
    public void testFirstPage() {  
        // Specify the project web directory for example: 'c:/dev/myproject/web'
        MockContainer container = new MockContainer("c:/dev/myproject/web");
        ...
    }
} 
Internally MockContainer creates an instance of MockContext and a number of Servlet stubs. Below is the list of stubs created:
MockContainer provides various getters to for accessing the Servlet stubs.

It is also possible to set your own stub instances on MockContainer through setter methods. If you set your own stubs, MockContainer will use those instead of creating its own default instances.

Once created you need to manage the container life cycle through the methods start and stop.

public class IntegrationTest extends TestCase {
    public void testFirstPage() {
        // Specify the project web directory for example: 'c:/dev/myproject/web'
        MockContainer container = new MockContainer("c:/dev/myproject/web");

        // Bootstrap the container  
        container.start();  

        ...

        container.stop();
    }
} 

Http request parameters can be set through MockRequest.

MockContainer also provides a number of convenience methods for this very purpose namely MockContainer.setParameter(String, String) and MockContainer.setParameter(String, File, String).

To set request attributes use MockContainer.setAttribute(String, Object).

The example below shows a complete test:

public class IntegrationTest extends TestCase {
    public void testFirstPage() {
        // Specify the project web directory for example: 'c:/dev/myproject/web'
        MockContainer container = new MockContainer("c:/dev/myproject/web");

        // Bootstrap the container  
        container.start();  

        // Set the form name to ensure a Form submission occurs
        container.setParameter(Form.FORM_NAME, "form");

        // Set the field value as a request parameter  
        container.setParameter("myfield", "one");

        // Simulate a user requesting the page, FirstPage. FirstPage will forward to SecondPage.  
        FirstPage page = (FirstPage) container.testPage(FirstPage.class);  

        // Assert that FirstPage does indeed forward to SecondPage
        Assert.assertTrue(SecondPage.class, container.getForwardPageClass());

        // Assert that the Field named "myfield", was bound to request parameter "myfield"
        Assert.assertTrue("one", page.getForm().getFieldValue("myfield"));

        container.stop();
    }
} 
This example shows how to set a value to the field, called "myfield". Also note that the Form.FORM_NAME parameter is set otherwise Click will not process the form. Form.FORM_NAME must be set to the Form's name, called "form" in this example.

The Page output is available through MockContainer.getHtml().


MockContext

MockContext is useful for testing custom controls (components).

Note that it is not necessary to specify a web directory when using MockContext.

For example:

public class ValidationFieldTest extends TestCase {
     
    public void testValidationField() {
      
        // Initialize the context.
        MockContext context = MockContext.initContext();
        
        ...
} 
MockContext provides a number of initContext that prepares and initializes the context:
The MockContext.initContext methods creates a number of Servlet stubs. Below is the list of stubs created:
The example below shows how MockContext can be used to test a custom Control called ValidationField:
public class ValidationFieldTest extends TestCase {
     
    public void testValidationField() {
      
        // Initialize the context.
        MockContext context = MockContext.initContext();  
         
        int maxLength = 10;  
        String fieldName = "name";  
        ValidationField field = new ValidationField(fieldName, maxLength);  
   
        // Retrieve the request and set field request parameter.  
        MockRequest request = context.getMockRequest();  
        request.setParameter(fieldName, "value");  
   
        // onProcess binds the request attribute and field value  
        assertTrue(textField.onProcess());  
         
        // Assert that the field is still valid.  
        assertTrue(textField.isValid());  
    }
}