Extreme Java When vanilla Java is not enough


TDD with Wicket

I'm starting to get in love with Wicket. I can easily isolate webpages, programming and testing. While my fictional webdesigner makes evil plans about the pages, my programmer (that's me) can develop all pages using TDD. And I'm not only talking about making unit tests for UI. I'm talking about creating the test BEFORE the implementation. See how I'm achieving this:

Let's create a new page. Since the design will be made by the designer, I only invest on the essential tags. But, even before creating my HTML, I can create the tests. From the requirement, I will have two screens: one list of all cities grouped by state, and a page with a list of vCards for that city. First, the tests (after all, it's TDD!):

public void testRendering() {
  WicketTester t = new WicketTester(CitiesPage.class);
public void testStateBinding() {
  WicketTester t = new WicketTester(CitiesPage.class);
  t.assertComponent("states", ListView.class);
  t.assertListView("states", getStates());
  t.assertComponent("states:0:name", "name-of-first-state");
public void testCityBinding() {
  // new tester, start, assertList...
                               NextPage.class, "city=0");

I put all tests here for simplicity, but, in TDD, I create only the first test, then correct, go for the second and so on. This will fail. I solve by creating the stub page and the bindings:

<div wicket:id="states">
  List of State <span wicket:id="name">Lorem ipsum</span>
  <div wicket:id="cities">
    <span wicket:id="name">City's name</span>
    <a href="#" wicket:id="link">Go for it</a>

And, the Wicket's WebPage constructor:

public MyPage() {
  add(new ListView("states", getStates()) {
    protected void populateItem(ListItem item) {

And, the best part of TDD is I can make my code step-by-step: I implement the list binding, then I implement the list iteration, then, the cities binding inside "populateItem", until I finish the page. Much easier than implementing then testing. And it's a lot error-proof, too. When we make the code before the test, it's common to make a test that "just works" and having a lot of small glitches. Thinking about the test first, we develop code that needs to pass the requirements.

I finally fulfilled my dream of doing real TDD, from UI to persistence! Thanks wicket team! Now, I only hope it does not have any performance (or security) problems.

The last step (that usually takes huge time from me) is making a design that fits the code. But this part will be darn easy: I make a free (as in "freedom") design with a WYSIWYG editor and add the wicket markups, testing it direct on Safari/Firefox/IE/Opera, without the need of a slow "edit-deploy-run-test" cycle (mandatory for JSF or similar).

Filed under: Java EE Leave a comment
Comments (0) Trackbacks (0)

No comments yet.

Leave a comment



No trackbacks yet.