Take the case of a search feature for a website. If a ‘refine’ parameter is present, the user should be shown a search form to refine their criteria. However if the refine parameter is not present the user is shown the search results for the query.

While this code will initially work, there is some ambiguity in the way the URLs are matched. The order in which the @RequestMapping mappings are defined in the class file is actually determining which method will be called. If we were to define the search() method first, then a request to search?query=dog&refine=true would satisfy the conditions for the search() method’s @RequestMapping and thus the params="refine=true" on the refine() method has no bearing on the outcome of the request.

To safeguard the controller against the potential reordering of methods in a class (which in usual Java programming has no affect on the outcome of running code), we need to ensure the parameter mapping is explicit.

By explicitly checking the refine parameter is not present for the search method’s request mapping (!refine=true), the declaration order of our @RequestMapping annotations in the class file has no bearing on which method handles the request thus making our code robust to the reordering methods. Similar precautions should be taken with the other attributes of @RequestMapping including method and headers.

1) Checkout codebase
This step only needs to be done once, it will pull down a local copy of the entire history allowing for very fast nagivation of revisions and allow work to be down when no connection to a central repository is available.

git svn clone svn://path/to/code/ --stdlayout

2) Create a topic branch to work on
We now want to start work on our first story, so we create a local branch for it. This allows us to keep all changes related to the first story out of the master branch. By keeping the master branch clean we can create as many local branches as we wish from it allowing us to quickly fix a bug in a separate local branch to the story we are working on. I’ll come to this later. The -b option means checkout and create a branch, this is a shortcut to creating the branch then checking it out.

git checkout -b story1

.. implement the first story ..

3) Add all new/deleted/modified files to staging area
With git you can stage just the files that are important, these staged items then make up the contents of your commit.

git add path/to/resource

4) Create a commit
We then create a commit of the staged files in our local branch, note this differs from SVN as a commit is only local.

git commit -m "My commit message"

5) Merge changes from your topic branch into the master branch
Ensure the master branch is up to date

git checkout master
git svn rebase

Then merge your topic branch into master

git merge story1

6) Merge conflicts
Merge any conflicts either manually or using mergetool (I’m yet to figure out how to use the mergetool command)

7) Push to SVN
This is the bridge that takes our Git commits and pushes them to SVN. Each Git commit will be mapped to a respective SVN commit.

git svn dcommit

Working with multiple branches
As I mentioned earlier, one of the major advantages of Git over SVN is the ability to have multiple working branches locally, allowing you to switch between them with relative ease. Take for example you are working on a story, it might take you a whole day to get it done. At midday an urgent support request arrives for a bug in the live software. Using SVN I would typically have to checkout the HEAD revision into a separate directory and import it into Eclipse as a new project. With Git it is much simpler, I use the following steps to do the switching.

# Commit all current work to the topic branch

git add path/to/noncommited/work

# Switch to the master branch and make sure it is up to date

git checkout master
git svn rebase

# Create a new branch for the bug fix

git checkout -b bugfix

# Fix the bug
# Follow steps 3-7 above
# Carry on working on the story

git checkout story1

Git GUI
You can use the Git GUI tool for most of the steps above, I find it particularly useful for steps 3 & 4.
You can also review the history and changes using gitk, this is useful for code reviews before you push your code into a master repo.

JGit (Eclipse Plugin)
I use the JGit Eclipse Plugin when working in Eclipse, it provides a diff with the previous version which I find invaluable.
Install in Eclipse using the update site: http://www.jgit.org/updates

References
http://blog.tsunanet.net/2007/07/learning-git-svn-in-5min.html
http://stackoverflow.com/questions/190431/is-git-svn-dcommit-after-merging-in-git-dangerous
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#resolving-a-merge

I have also created two little pages which demonstrate event bubbling and how the different behaviour mechanisms work with form submission (hint: try using Internet Exploder with the ‘live’ example).

A PDF version of the slides is available.

Thanks to my manager Phil, for letting me post this on my personal blog.

http://abehaviouralworld.rapaul.com/ is a little project just launched which attempts to distill behaviours from twitter. Given my recent rapture in the world of BDD, the behaviours we are distilling are those that match the scenario format.

Given ...
When ...
Then ...

If you look carefully at the page source, you will notice a large portion of it is dedicated to an HTML comment containing the list of features and the breakdown into scenarios. To keep things easily accessible, each time I thought of a scenario I added it to the page, once completed, it was marked with [Done].

For example, starting with the most important feature:

  Feature 1)
  In order to see how BDD syntax is being used on twitter
  As a BDD zealot
  I want to see tweets that contain 'given', 'when' & 'then', in that order.

I then broke this feature down into scenarios:

  [Done]
  Given the search returns more than matching 10 tweets
  When the user views the page
  Then the 10 most recent tweets should be displayed

  ...

Each time a scenario was satisfied, I marked it with [Done]. Not all scenarios ended up being all that important, the following scenario is still pending.

  Given the search returns no matching tweets
  When the user views the page
  Then instead of showing any tweets a message should be shown

In fact, if we attempt to tie this scenario back into the vision of the website (distilling behaviours in twitter), then we realise it adds no value. If no one is tweeting about behaviours, then it is highly unlike that anyone will be visiting our behaviour distillery.

There are a couple of features (3 & 4) in the source which haven’t yet been implemented.

  Feature 3)
  In order to emphasis the given/when/then syntax
  As a BDD zealot
  I want to see give/when/then highlighted in the displayed tweets

  Feature 4)
  In order to encourage BDD syntax usage on twitter
  As a BDD zealot
  I want to be able to tweet from this page using a BDD template

If anyone would like to work on these features, or even just break down some useful scenarios, please feel free to fork the code on github, provide me with a diff or add a comment (note at the time of writing github looks to be having some caching issues on the ‘Source’ tab).

What no executable scenarios?
Oops, nope. I’m yet to get into the world of writing executable scenarios in Javascript. If someone has some knowledge in this area, please feel free to fork the github repository and start automating the scenarios from the page source.

PS: This idea was partially inspired by a tweet by soulnafein which read:
My girlfriend is taking the mickey out of me because recently I started explaining things using the Scenario format (Given When Then) :-)

Below is a live calendar of the meetups I’m planning on attending,

I’ll try to keep this up to date, so feel free to subscribe to the calendar if you have similar interests (java, javascript, groovy, scala, testing, mocking, android, webOS, html5… anything you see in this blog’s tag cloud).

By breaking the test into given, when & then, future maintainers of the tests will more quickly understand which parts of the test relate to setup, exercising the SUT and asserting.

(stealing from Apple’s AppStore ad) What’s great about Eclipse, is that if you want to write a foreach loop, there’s a template for that. If you want to create a unit test, there’s a template for that. Yip there’s an app template for just about anything.

To minimise keystrokes and encourage the use of this style, you can modify the existing Test template as shown below to automatically generate the BDD style comments & statically import the BDDMockito members. To modify the template, navigate to Window > Preferences > Java > Editor > Templates. Click on Test (the JUnit 4 test template) and click edit. Paste in the follow template:

You are now ready to start writing BDDMockito style unit tests using Eclipse’s template, simply type Test, hit Ctrl+Space and you will be given the following option.

Selecting the option will generate the test method, focus first given to the test name, then to the blank line after // given.

There you have it, a simple Eclipse template to generate your BDDMockito style tests.

Intended Audience

This book is intended for Java web application developers who wish to learn about Spring Web Flow 2. A base knowledge of the Spring Framework and its associated MVC is advised, however most examples in the book provide sufficient detailing of the surrounding technologies and their integration points. This allows the reader to follow the examples without looking up details from other reference sources.

Chapter 1 – Introduction

The first chapter of this book provides a general introduction to Spring Web Flow 2 including some of the basic terminology. For those familiar with Spring Web Flow 1, there is a useful section detailing the major changes introduced in Web Flow 2. Having not used Spring Web Flow in over a year, I found the summary provided enough information to reacquaint myself.

Chapter 2 – Setup for Spring Web Flow 2

Chapter 2 details how to get Spring Web Flow setup in a Spring web application. Details on where to find the source code and examples provides a good starting point for users who wish to see Web Flow in action before delving into the details. An explanation of tooling support, such as setting up Eclipse to visualise flow, is a helpful addition especially with the prevalent screenshots.

Chapter 3 – The Basics of Spring Web Flow 2

As expected, this chapter covers the necessities for building a Web Flow, focussing on defining the flow using XML. This is by far the most important and useful chapter of the book. The chapter is just over 50 pages long, but is well worth the read as most sections are fundamental in using Web Flow, topics include: flow descriptors (including a diagram), flow scoped persistence, the newly supported EL expression language, scope levels, @Autowired behaviour gotchas, inputs & outputs, subflows and end states.

Chapter 4 – Spring Faces

Not being a JavaServer Faces (JSF) user, I skimmed over this chapter, however it is available as a sample chapter.

Chapter 5 – Mastering Spring Web Flow

This chapter contains a mix of topics. The first section includes further information on the usage of subflows, however I feel the explanation is a little brief.

The next section talks about integration with the Spring Javascript project. Spring Javascript is explained as being an abstraction layer on top of existing toolkits (only Dojo supported so far), but the example given has a hardwired dependency on dijit.form.DateTextBox. I’m not sure if this is just a bad example or if that is how Spring Javascript works. An introduction to the Tiles framework is then given and tied in nicely with an explanation of how to load page fragments using Spring Javascript.

The final section in this chapter covers advanced configuration of flows. I would advise using this section purely as a reference as it is heavy on detail.

Chapter 6 – Testing Spring Web Flow Applications

Being a bit of a testing zealot, this was the section I was really hanging out for. The opening sentence reads, “Testing is an important aspect in every software development process”. Off to a good start, unfortunately this chapter didn’t live up to my expectations.

The Web Flow specific test setup and assertions are explained well, for example calls such as context.setEventId("login"), this.resumeFlow(context) and assertFlowExecutionEnded().

The example then introduces EasyMock to help isolate and focus the unit tests. However this example has a glaring issue; it creates a mock of the wrong object. The example models a user login using a UserService to fetch a user by username. You would expect the mocked object in this case to be the UserService, but the example mocks out the underlying EntityManager. As a result the unit test for the flow ends up setting expectations on Hibernate HQL, thus polluting the flow’s unit test with database queries that should really be tested at the service or DAO layer. If you change the way users were fetched in the DAO (or you moved away from Hibernate) you wouldn’t expect your Web Flow tests to be affected.

My advice when reading this chapter is to skip to the section titled More testing with EasyMock. This section shows correct usage of EasyMock and demonstrates a test driven approach to testing.

Chapter 7 – Security

The final chapter covers the integration of Spring Security, the only real option for security in Spring. The details in this section are largely not specific to Spring Webflow, however they are important for developing any non-trivial application and are well explained with examples.

Conclusion

I would recommend this book to any developer new to Spring Web Flow. The concepts and much of the implementation between Web Flow 1 and 2 remains the same, meaning this isn’t an essential read for existing Web Flow users.

I’ve attached the final outcome of the live TDD examples. Obviously TDD doesn’t come across very well as a final solution, however the code also provides basic examples of the Mockito and Rhino Mocks libraries. The code style is based on Spring Framework’s annotation driven MVC framework.

Java example code – JUnit, Mockito, EclEMMA (Eclipse Java coverage)
VB.Net example code – NUnit, Rhino Mocks

I also modified the javascript console created for my previous blog entry to use Dojo. You can download the source to try out Dojo examples on your local box. You will need Java and Grails installed and can run the server using the usual grails command.

The console can then be accessed at http://localhost:8080/AjaxServer/ (only tested in Firefox).