BDD in Java with easyb (John Ferguson Smart)

John started out by arguing that TDD is not about testing, it's about writing better code. That is, it's about making your code more maintainable, flexible, reliable and simple. TDD is forces the programmer to think about how to test the class before actually writing the class. BDD, on the other hand, helps to determine what to test and to write more focused code, by starting with the behavior. Instead of thinking that you're testing your class, you should think that you're validating your requirements!

easyb is a BDD testing framework for Java, written in Groovy (hence providing full access to all Java API's). It ensures that tests become clearer and easier to both write and read! It helps the developer to focus on the requirements only. A competitor to easyb is JBehave, which is an extension to JUnit. However, according to John, JBehave is more cumbersome than easyb.

easyb makes use of stories, much like the story cards in the Agile world. In a story, a narrative approach is used to describe a precise requirement. In easyb, a story could look like this:

 
scenario “Make initial deposit onto a new account”, {
	given “a new account”
	when “an initial deposit is made”
	then “the balance should be equal to the amount deposited”
}
 

This scenario is quite clear and readable, isn't it!? Furthermore, it's self-documenting - a very appreciated feature =) And the syntax is so trivial that even a non-technical stakeholder would have no problem understanding it. The developer can then reuse the given scenario (pseudo) code and implement the test case, like this:

 
import com.mycompany.bankonline.domain.Account
 
scenario “Make initial deposit onto a new account”, {
	given “a new account”, {
		account = new Account()
	}
	when “an initial deposit is made”, {
		initialAmount = 100
		account.makeDeposit(initialAmount)
	}
	then “the balance should be equal to the amount deposited”, {
		account.balance.shouldBe initialAmount
	}
}
 

The shouldBe call is an intuitive and readable way to verify that the requirement holds. Another way to verify the outcomes is to use the ensure syntax. Example:

 
ensure(account.balance > 0)
 

or

 
ensure(account) {
	has([balance:100])
}
 

easyb could be extended to use DBUnit (and further plugins for Grails and Excel are on the way). On the IDE support, the only good option is IntelliJ IDEA. It really comes down to the Groovy support, and Eclipse and NetBeans doesn't shine here. In those cases, you're better off running the tests in Maven or Ant, which both are well supported. In the upcoming version, easyb will have full support for Continuous Integration (CI), enabling automatic test execution in a CI-server such as Hudson.

Furthermore, easyb comes with a web application - Easiness (cmp. Fitnesse) - where stakeholders can create stories in plain text. The developers can then go ahead and implement the stories defined by the stakeholders. This is an important features, that further improves the cooperation between the customer and the provider. It really seems like a quite nice little framework! If you agree, have a look at it at http://easyb.org/.

From Concurrent to Parallel – Library-based parallelism in JDK 7 (Brian Goetz)

Brian is an expert in the concurrency area, but he's not a good presenter! He speaks faster than I can read, and his slides are so packed with info that he doesn't have time to say the half of it. That put aside, in this very interesting session Brian presented some really cool concurrency features to be included in JDK 7.

As you probably know, JDK 5 introduced a set of very useful classes for course-grained parallelism. JDK 7 will introduce a framework for fine-grained parallelism - the "fork-join" framework.

We have now reach a point in time when Moore's laws isn't valid anymore. The new reality is not faster CPUs but more CPUs. To adapt to these changes, programmers have to change the way they think about parallelism. The unit of work (UoW) that represents a task to be solved must be split into even smaller parts to be able to keep all hardware busy. Nowadays, it isn't enough to for ex. spawn a new thread for each service call in a server, the UoW must be split up even further.

Examples of finer-grained parallelism is searching, sorting and filtering a data set. Such a task is preferably solved by dividing it into sub-problems and combining the sub-results at the end. We could use the course-grained concurrency tools (for ex. Executor + Future) introduced in JDK 5 to solve this problem. However, with multiple CPUs available, these tools doesn't perform optimally. For ex., the shared work queue in the Executor becomes a bottle neck when the number of threads/CPUs increases. Furthermore, these tools provide no form of load balancing, i.e. if one thread finishes before the others, it is never reused.

The divide-and-conquer algorithm could also be applied to solve the problem. This great advantage of this approach is that it's independent of the number of CPUs used! Using plain threads for this approach is too expensive though, since thread creation costs way too much. However, the fork-join-operation in JDK 7 solves problems like these using the divide-and-conquer algorithm in a much more effective way! Internally, it uses an slim thread pool to overcome the cost of thread creation. Furthermore, no data-copying penalty exist since the data set (for ex. an array) is not divided/copied during the solution. Instead, the indexes within the data structure is used to define each data subset. Another advantage is that the code doesn't know how many CPUs it executes on, hence it's portable!

While the Executor (JDK 5) should be used for tasks consisting of both IO and computing, the fork-join-operation (JDK 7) should be used for highly compute-intensive tasks. Examples of such tasks are matrix operations, numerical integrations and game playing. The JDK 7 class to be used for these kind of problems is ParallelArray. It's a utility class that greatly simplifies the work of solving a task in parallel. You can think of it as an in-memory database for data sets. Typical usage is:

 
ParallelLongArray pa = ParallelLongArray.createUsingHandoff(array, forkJoinPool);
long max = pa.max();
 

The ParallelArray class provides operations for:

• Filtering (nestable)
• Mapping
• Replacement
• Aggregation (max, count, sum, ...)
• Application (one action performed for each selected element)

To compare, the ParallelArray class acts much like the Map-Produce concept introduced by Google but it works in a different domain (local system instead of in a distributed system).

The only downside really is that JDK 7 isn't scheduled until mid 2010, meaning we'll have to wait quite some time before we can actually use these new concurrency features. But from the looks of it ... it may be worth the wait!

The SpringSource DM Server (Joris Kuipers)

The reasons why SpringSource decided to develop a new application server were many. Today, modularity is important and developers spend much time on achieving it in their applications (layering, separation of concerns, etc.). However, when the application is deployed, all modularity is lost - the deployable unit is one huge, monolithic WAR file. That means that sharing code (let alone services) between applications become hard if not impossible. In order to perform the smallest update on the application, whole WAR file have to be redeployed. Furthermore, the servers themselves lack modularity; they come prepackaged with a lot of modules but there's no way to configure that your application only make use of a couple of them. Hence, they are all left in there, consuming unnecessary CPU cycles and memory.

The DM (Dynamic Modules) server was developed to tackle these issues of non-modularity. In order to achieve true modularity, is has been built on top of OSGi (namely the Equinox container). Since OSGi can be quite hard sometimes, the DM server conceal the complexity of OSGi in the same way as the Spring framework does with for ex. Remoting or JMX.

In order to be able to use a third-party library from within the DM server (and from any other OSGi containers), the standard JAR library needs to be extended with OSGi-specific meta data - the OSGi manifest. SpringSource has therefore created the Enterprise Bundle Repository, where they have started to upload and publish OSGi-ified Java EE libraries. If you're using Maven or Ivy, the bundle repository can easily be configured as a remote (or local) repository.

The DM server also introduces a couple of new OSGi import constructs, enabling ease of development. One example is the "Import-library" that can be useful if you want to make use of a framework (for ex. Spring) but don't want to waste your time having to specify every single Import-package (for example Spring-Remoting) within the framework (as you normally would have had to do). This doesn't affect performance improvement since (thanks to OSGi) none of the pre-installed bundles are loaded before they are actually used! Furthermore, with the DM server it's now possible to remove the library bloat of monolithic Java EE WARs. Instead of building the external libraries into your WAR, you can instead declare them as dependencies in the OSGi manifest headers. The server will then convert these into plain "Import-package" constructs during deployment. That way, the size of the built/deployed WAR can be reduced significantly!

In the DM server, one can of course deploy plain OSGi bundles but also WARs, EARs etc. Typical scenarios for deploying a plain OSGi bundle are stand-alone libraries, global services and small stand-alone applications. However, being able to deploy a bundle is not enough in most cases ... A normal application normally consist of multiple bundles, which becomes hard to un/deploy since there is no single deployable unit. Furthermore, with multiple bundles you don't get a common log file or a notion of an application scope. To tackle this issue, the DM server adds the notion of an application by introducing the PAR (Platform Archive) format. It's basically a JAR with a number of 'Application-*' manifest headers. You can think of it as an EAR in Java EE. PARs are versioned and the versions apply to all of their bundles. This mean that one can deploy a PAR twice with different versions but with the same bundles, without conflicts.

The DM server comes in several versions. Of course there's the community version, using a GPL and SpringSource license. Then there's the commercial license where full support from SpringSource is included. On the extension side, better Maven support will soon be released so that the dependencies can be specified in a single place (not like now when you have to duplicate them in the pom and in the manifest). There's a Eclipse-plugin available that enables re/deployments from within the IDE.

These are some of the features in the DM server. There are plenty or more cool ones, read all about them here. There, you'll also find a lot of sample applications that can get you going! With the DM server, SpringSource feel that they are filling the (up until now) empty space of server side OSGi and states that "The DM server is the healthy new way to run your apps!". I must say it looks very promising! Why don't you go ahead and try it out!? I know I will!

If you appreciated these posts, you will definitely enjoy next years conference! Pick up your calendar and reserve December 2009 for a great week at Devoxx!

The main goal of Behaviour Driven Development, a TDD based methodology, is to identify behaviours in both the analysis and the design phases.
In BDD [1] the test code looks more like a specification of behaviours than a test of the production code.

Test Driven Development

TDD can be summarized in one rule:
“Writing code is only allowed if you have a failing unit test”.

The TDD development cycle:
1. Write a unit test
2. Run all tests and make sure the new one fails
3. Implement the simplest possible solution in order to make the test pass
4. Refactor the code. All tests must pass after the refactoring has been done.
5. Repeat - write a new unit test

Problems:

• Unit tests suggest a strong relationship between test class and implementation
  class. Each class or method usually has a corresponding test class or test meth-
  od. This causes a high coupling between the class under test and the test case.
  It also means that we focus too early on the implementation details, instead of
  doing the design first.
• Unclear definition of granularity of units. A common mistake is to mix up unit test with integration tests - which may require complex setup of several com-
  ponents (like a database). Having a high coupling between test code and the
  implementation is a serious problem when later on refactoring is needed. In-
  stead one should use mock objects to explore interactions between objects.
• Limitations on mock objects may have too big an impact on the design. We
  often have to stop using the private, static and final keywords. This problem was
  discussed in the previous issue of JayView - Mocking Static Methods.

The Marriage of Component
Specification with Unit Test

BDD has a similar development cycle, but instead of writing tests before coding you
write specifications before coding.
A specification consists of a description of behaviours which are expressed within a
context. Behaviours become self-verifying by writing (coding) expectations in the
form of examples. The specification is written in an executable form so that we can
generate a readable specification and verify that its expectations are valid.

Example

For example let’s write a specification for a stack. We start by identifing its contexts,
which are: “empty”, “neither empty nor full”, “full”. Example of behaviours for the
empty context are: “should be empty”, “should not be empty after a push”. For each
of those one continue to write expectations. Like TDD you specify a small set of
behaviours at a time then implement it - short iterations.
Let’s show how this can be done using standard JUnit since it is a well known
tool. JUnit is not a good tool for doing BDD since it was only designed for doing
testing. A more suitable tool is for example JDave [4] or RSpec [2] which let you
create much more readable specification. (The analysis part of RSpec is shown in
the next section).

// The enclosed annotation makes JUnit run all inner classes as tests
@RunWith(org.junit.runners.Enclosed.class)
public class StackTest {
    public static class EmptyStack {
        private Stack stack;
        @Before
        public void before() {
            stack = new Stack();
        }
        @Test
        public void shouldBeEmpty() {
            assertTrue(stack.isEmpty());
        }
        @Test
        public void shouldNotBeEmptyAfterAPush() {
            stack.push(“Some value”);
            assertFalse(stack.isEmpty());
        }
        // ...
    }
    public static class NeitherEmptyNorFullStack {
        private Stack stack;
        @Before
        public void before() {
            stack = new Stack();
            stack.push(“x”);
        }
        @Test
        public void shouldAddToTheTopWhenSentPush() {
            stack.push(“y”);
            assertEquals(“y”, stack.peek());
        }
        // ...
    }
}

By replacing the word “test” with “should” and organizing tests around behaviours it
becomes clear that we are using BDD to drive the design.
This format also allows us to generate an even more readable specification by using
for example the junitreport ant task with a custom style sheet that extracts the bold
words. A proper BDD tool would have this ability built in. I believe this specification
is much better than the (class) javadoc that are often missing or incorrect.
As shown above we keep specification and test together in an executable unit. This
approach can also be used at a system level.

The Marriage of Application
Requirements with Acceptance Tests

Requirements and acceptance tests are captured using a template containing a story
and one or more scenarios.
As a Role, I want Feature, So that Benefit
Scenario1: Given ... When ... Then
Scenario2 ...
A story’s behaviour is its acceptance criteria - the scenarios. By using the template
above we can collaborate on stories with customers. This is nothing new, it is just
one way of doing analysis.
What is new is that in BDD the specification is written down in an executable
unit in order to have self-verifying tests. The Ruby RSpec tool has a slightly different
approach. It can treat specification written in plain english as an executable unit.

An example of a story:

Story: transfer to cash account
As a savings account holder
I want to transfer money from my savings account
So that I can get cash easily from an ATM
Scenario: savings account is in credit
Given my savings account balance is 100
And my cash account balance is 10
When I transfer 20 from my savings account to my cash account
Then my savings account balance should be 80
And my cash account balance should be 20
Scenario: savings account is overdrawn
Given my savings account balance is -20
And my cash account balance is 10
When I transfer 20 from my savings account to my cash account
Then my savings account balance should be -20
And my cash account balance should be 10

To perform verification on this specification we create an interpreter where we de-
fine reusable test steps.

class AccountSteps < Spec::Story::StepGroup
  steps do |define|
    define.given("my $account account balance is $balance") do |account,
balance|
      @accounts ||= {} # creates a new hash if @accounts is nil
      @accounts[account] = Account.new(balance.to_f)
    end
    define.then("my $account account balance should be $amount") do |account,
amount|
      @accounts[account].balance.should == amount.to_f
    end
    define.when("I transfer $amount from my $from account to my $to account")
do |amount, from, to|
       @accounts[from].transfere_to(@accounts[to], amount.to_f)
    end
  end
end

To run it we need to tell which steps are using what story:

runner = Spec::Story::Runner::PlainTextStoryRunner.new(filename-of-the-story)
runner.steps << AccountSteps.new
runner.run 

RSpec matches each line in the story with the defined test steps. The code inside the
define block will be executed if a match is found.
For example, when the story runner reads the line “Given my savings account bal-
ance is 100” it will execute

@accounts['savings'] = Account.new("100".to_f).

That means a new account object is created and stored in the accounts hash.

Still stuck with Java ? Psst, you can use JRuby [5] to test and mock Java
objects. For example, try the JtestR [6] tool which also integrates nicely
with ant, maven and Buildr [3].

Conclusions

There is not a big difference between TDD and BDD if TDD is used correctly. TDD
often causes brittle test code - a small change in the production code may cause a
major change in the test code. BDD gives the possibility of structuring tests to make
them “refactoring friendly”. This is accomplished by organizing tests in small focused
examples of behaviours.
People are not always aware that TDD is able to drive the design. By not thinking
in terms of tests but instead describing the what and why of behaviours, it becomes
clear that BDD is a methodology for analysis and design.

References

[1] BDD - http://behaviour-driven.org/
[2] RSpec - http://rspec.rubyforge.org/
[3] Buildr - http://buildr.rubyforge.org/
[4] JDave - http://www.jdave.org/
[5] JRuby - http://jruby.codehaus.org/
[6] JtestR - http://jtestr.codehaus.org

Originally published in JayView.