Posts Tagged: ‘JUnit’

XPages: Java Interfaces Java and Test Driven Development

15. Oktober 2015 Posted by Bernd Hort

A word of warning: the following article is quite lenghty and abstract. It basically says that using Java Interface in your XPages projects leads to better (that means more maintanable) code and that with the help of the OpenNTF project org.openntf.junit.xsp a developer can utilize Java Interfaces to write better test code for their XPages projects.

I have to confess that when I started with Java Development some time ago I didn't like Java Interfaces. While in some cases I could see that they are useful most of the time they gave me a hard time trying to understand the code of someone else. My usual approach for reading someone else code is to figure out how to invoke the part I'm interested in and then take a close look at the parameters that are passed to the method and the return value. Interfaces due to their nature shield the implementation.. But that the part I was interested in. Searching for the current implementation made it more complicated.

Since working with XPages my preferences had completely changed. Like most of the Notes developer which start with Java my code used to be small. If you write some Notes Agent to invoke a Web Service or generate a PDF document there is normally not much need for an elaborated design of your class hierarchy.

But nowadays as we developed our own XPages framework totally Java based the rules and approaches must cope with the arising complexity. One aspect were Java Interfaces helps us is the Open/closed principle. Simply speaking the Open/close principal state that code should be open for extension but closed for modification. With modification are those meant that leads to changes in calling methods and therefore are costly and error-prone. If you find a better way to implement an algorithm inside your class no one will complain. But if there is change in your API resulting into the necessity to change code in a lot of calling methods things might get messy.

By using Interfaces as parameters and return values it is like having a contract. The caller of your method can rely on whatever will be passed to the method and returned from it will work as long as it implements the Interface. If you write a new class which is way faster than your old code you can use it instead without worrying that you break something. This is true as long as the new code implements the same Interface. If you find a cool new OpenSource library which you would like to use instead and it does not implement the Interface, you can simply write a wrapper for it.

To believe nothing breaks by your change is one thing. To know it, is another thing. This is were Test Driven Development and JUnit Testing comes in. The idea to walk away from any change you made and to be absolute confident that everything works is amazing.

My first steps using JUnit were a little bit frustrating because there is no way to run JUnit test in Domino Designer directly for your XPages Java code due to the virtual file system a NSF is from Eclipse point of view. So I had to export my Java code and then run JUnit tests in a stand alone Eclipse.

I really was delighted when I read about the OpenNTF project org.openntf.junit.xsp. This project allows to execute the JUnit Tests from within an XPage.

One of the challenges with writing test code is that with systems running in a special environment like XPages you have to find a way to have living objects from this environment. A way around this issue is to use a mock object. And again with Java Interfaces this is easy. Instead of basing an existing Notes document to your test code you could pass a mock up object since lotus.domino.Document is a Java Interface. So there is no need to have a Notes Session, a Notes Database and a existing Notes Document that meets your test requirements for now and all the future to pass your JUnit test.

Christian Güdemann did a great job integrating EasyMock into org.openntf.junit.xsp. Read more in his blog post "org.openntf.junit.xsp – now with EasyMock support".

Have a closer look into using Java Interfaces today. They really help you.

Happy coding!

Testing XPages (2): BrowserMob Proxy

17. September 2015 Posted by Sven Hasselbach

When testing XPages or other web applications, you may want to have more control about the requests and responses during the JUnit testing. For example, if you want to test if a specific HTTP header exists in the response, or if it is required to add some HTTP headers to the request. But you cannot doe this out of the box with Selenium. Instead, you have to add a proxy to the Firefox controller, which then gives you a handle to the HTTP data and allows you to control the flow.

An good solution for this is BrowserMob Proxy, which can be used by adding the required dependency to your Maven pom.xml:


[This is version 2.0.0, the latest stable version]

The proxy runs locally on the specified port as soon the JUnit test starts and ends automatically after finishing the tests.  In order to accomplish this, the setUp method has to be modified:

// start the proxy (listens on port 4444)
server = new ProxyServer(4444);

// get the Selenium proxy object
Proxy proxy = server.seleniumProxy();

// configure it as a desired capability
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(CapabilityType.PROXY, proxy);

Now, the proxy setting must be added to the Firefox driver:

driver = new FirefoxDriver(capabilities);

In the test class, three global variables must be defined; these are giving you access to the proxy server and latest the request and response during testing:

private ProxyServer server;
private BrowserMobHttpResponse httpResponse;
private BrowserMobHttpRequest httpRequest;

With the help of a ResponseInterceptor, the httpResponse property is always filled with the latest response. To initialize it, an anonymous class in the setUp method has to be created:

// add a response interceptor
ResponseInterceptor interceptor = new ResponseInterceptor() {
    public void process(BrowserMobHttpResponse response, Har har) {
          httpResponse = response;

// add the interceptor to the server

For the RequestInterceptor it is the same procedure:

// add a request interceptor
RequestInterceptor requestInterceptor = new RequestInterceptor() {
    public void process(BrowserMobHttpRequest request, Har har) {
       httpRequest = request;


Now, it is possible to use it in a JUnit test:

public void testDemo() throws Exception {
    // add a request header
    server.addHeader("X-FOO", "BAR");
    // load the page

    HttpResponse httpRawResponse = httpResponse.getRawResponse();
    assertTrue("HTTP/1.1 200 OK".equals(httpRawResponse.getStatusLine()
    assertTrue( "Lotus-Domino".equals( httpResponse.getHeader("Server")) );

The Browsermob-proxy has a lot of additional features: You can modify the allowed speed for up- and downstreams, use basic authentication, upload files, etc.

Testing XPages

16. September 2015 Posted by Sven Hasselbach

When testing XPages with Selenium, you can easily pre-generate the JUnit test code with the browser plugin. But when you then change the structure of the XPage (f.e. by moving the components from an XPage to a custom control), all the IDs of the JUnit test will not work anymore.

That’s why it is better to use CSS selectors to access the generated fields:


With the selector „id*=’idOfTheComponent'“ you can access the elements by their component id, idependently of their full generated client id.

Here is an example with a small XPage with a radio group and a listbox:


A simple XPage to test (SimpleDemo.xsp)

<?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="">

        <xp:selectItem itemLabel="1" itemValue="1" />
        <xp:selectItem itemLabel="2" itemValue="2" />

    <xp:listBox id="listBoxSimpleDemo" multiple="true">
        <xp:selectItem itemLabel="1" itemValue="1" />
        <xp:selectItem itemLabel="2" itemValue="2" />
        <xp:selectItem itemLabel="3" itemValue="3" />

 The JUnit Test

package ch.hasselba.xpages.test.seleniumdemo;

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import static;

import java.util.List;
import java.util.concurrent.TimeUnit;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.firefox.FirefoxDriver;

public class SimpleDemo {

	private WebDriver driver;
	private String baseUrl = "";
	private StringBuffer verificationErrors = new StringBuffer();

	public void setUp() throws Exception {
		driver = new FirefoxDriver();
		driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

	public void tearDown() throws Exception {
		String verificationErrorString = verificationErrors.toString();
		if (!"".equals(verificationErrorString)) {

	public void testDemo() throws Exception {
		List elemRadio = driver.findElements(By

		Select select = new Select(driver.findElement(By
		List listSelect = select.getOptions();
		for (WebElement listElem : listSelect) {


	public void reloadPage() {

The Maven pom.xml file

<project xmlns=""