John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 125 posts at DZone. You can read more from them at their website. View Full User Profile

Web Testing BDD-style With JWebUnit and Easyb

08.17.2009
| 5734 views |
  • submit to reddit

Behaviour-driven development is a great way to design and build the web layers of your application. In this article, I look at how to use JWebUnit, a fast and light-weight web testing framework, with Easyb, a powerful Groovy-based BDD framework.

JWebUnit is a web testing framework built on HTMLUnit. It runs in memory, so it's fast. However, it also has an intuitive, high-level API, making it easy to use even if you have only an approximate idea of the exact HTML details of your application screens. A simple JWebUnit test case is shown here:

import net.sourceforge.jwebunit.junit.WebTestCase;
import net.sourceforge.jwebunit.junit.WebTester;

public class TestJWebUnitDepositStoryUI extends WebTestCase {

	public void setUp() {
		setBaseUrl("http://localhost:9090/ebank-web");
	}
	
	public void testDepositingCashShouldAddToBalance() {		
		beginAt("/");
		assertTextPresent("Current Balance: $0");
		setTextField("depositAmount","100");
		clickButtonWithText("deposit");
		assertTextPresent("Current Balance: $100");
	}
}

JWebUnit works fine like this, but we can still do better by adding a little BDD-flavoring to the mix. As it turns out, behaviour-driven development (or "behaviour-driven design") is a great way to model user interaction with your application. In BDD, you structure your requirements in a "given [some condition or state], when [some event occurs] then [we expect something else to happen]". For example, in an online banking application, one such requirement could be "Given that I am logged onto the bank web site and my bank account balance is $0, when I deposit $100, then the new balance should be $100."

Easyb is a behaviour-driven development (BDD) framework for Java and Groovy applications. It is based on Groovy, but uses a special DSL to express requirements and tests in BDD-style. Like many BDD frameworks, easyb lets you express your requirements (more precisely, your user's behaviour) in almost plain English, before filling in the details with test code. For example, here is a working Easyb test scenario describing how we might interact with our banking application:


scenario "Deposit cash via the web interface", {
given "the application home page is displayed"
and "the current balance is 0"
when "I type \$100 in the 'deposit cash' field"
and "I click on the 'deposit' button"
then "the new balance should be \$100"
}

As far as Easyb is concerned, this is executable test code - however it won't do very much. When you run Easyb against a scenario like this one, it will be flagged as "pending implementation". So now let's see how we can implement this test using JWebUnit.

JWebUnit test cases need to extend the WebTestCase base class. This makes the framework hard to integrate with JUnit 4 or with pure Java-based BDD frameworks such as JBehave. However, Easyb is built on Groovy. With a little Groovy magic, we can embed a JWebUnit client inside our Easyb test scenarios. The only trick is that we still need to have a class that extends WebTestCase, as it is an Abstract class. We also need to initialize the internal 'tester' member variable with an instance of the WebTester class. A simple Groovy class like this will do the trick.

class DepositCashWebClient extends WebTestCase {

    public DepositCashWebClient() {
        tester = new WebTester();
    }
}

We also need to create a new instance of this class for each test case. We can do this using the Easyb "before_each" keyword, as shown here:


before_each "initialize a web client", {
given "web client is up and running", {
webClient = new DepositCashWebClient()
webClient.setBaseUrl("http://localhost:9090/ebank")
}
}

Our full Easyb test story looks like this:

import net.sourceforge.jwebunit.junit.WebTestCase;
import net.sourceforge.jwebunit.junit.WebTester;

class DepositCashWebClient extends WebTestCase {

    public DepositCashWebClient() {
        tester = new WebTester();
    }
};
    
before_each "initialize a web client", {
  given "web client is up and running", {
      webClient = new DepositCashWebClient()
      webClient.setBaseUrl("http://localhost:9090/ebank")
  }
}

scenario "Deposit cash via the web interface", {
    given "the application home page is displayed", {
      webClient.beginAt("/")
    }
    and "the current balance is 0", {
      webClient.assertTextPresent("Current Balance: \$0")
    }
    when "I type \$100 in the 'deposit cash' field", {
      webClient.setTextField("depositAmount","100")
    }
    and "I click on the 'deposit' button", {
      webClient.clickButtonWithText("deposit")
    } 
    then "the balance should be \$100", {
      webClient.assertTextPresent("Current Balance: \$100")
    }
}

And running these easyb scenarios will generate you a report that looks like this:

Picture 5.png

Although this seems longer than the Java version, it is arguably more readable, and reflects the intention of the code more accurately than the Java equivalent. The test report also makes it quite clear what requirements are being tested, in very readable terms. Writing the tests using a BDD approach also helps you keep a good perspective on how closely your application actually does what your users have asked for. Reports like the one above can also give users and testers a better understanding of what is being coded.

I will be talking about EasyB and BDD along with Lasse Koskela at Agile 2009 next week in Chicago, in a talk called Executable requirements: BDD with easyb and JDave. So, if you are interested to learn more about BDD, come along!

From http://weblogs.java.net/blog/johnsmart/

Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Walter Bogaardt replied on Mon, 2009/08/17 - 7:17pm

The only problem with web development testing, is that web pages change so quickly that maintaining your tests is quit a bit more burdensome. Ideally some way to automatically record a user's actions and generate a test is much better. This is one reason, I like using selenium.

The other problem with web testing is the layers of ajax and javascript sometimes breaks web testing tools. Just thinking of how difficult it was to deal with deeply nested JSF application made me cringe on trying to web test it.Simply by virtue that JSF was developed and never had unit testing in mind to help simplify web unit testing process.

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.