To get started, let’s break down our validation needs along the standard lines that we see in frameworks today.  Widgets need to be able to be Validatable.  That is to say, Widgets must be able to be externally seen as having the capability to execute logic which validates their current state.  In my approach, I’ve chosen to strategize my widgets rather than visit them in order to validate their data.  This decision is largely to enforce contract-driven development and ensure a high level of testability.

Validatable

package com.ryannorris.gwt.validation.client;
 
public interface Validatable {
	/**
	 * Execute validation on the implementing component
	 *
	 * @return true if validation succeeded, false if validation failed
	 */
	public boolean validate();
}

We also now need an interface that will provide the rules for how validation logic should occur.  Something that is Validatable should be able to validate itself with multiple sets of rules.  Our Validator interface gives us this flexible cardinality, and has a familiar ring to it.

Validator

package com.ryannorris.gwt.validation.client;
 
public interface Validator {
	/**
	 * Execute the implemented validation logic
	 *
	 * @return true if validation succeeded, false otherwise
	 */
	public boolean validate();
}

Yes, these two interfaces are the same besides their name. They are both command interfaces, allowing us to abstract logic behind a single method that we can cope with polymorphically. The idea remember is that Validatable components can re-use many different Validator implementations.

So let’s write a simple Validator and Validatable interface.  In this case, we’ll be validating date input.

DateFormatValidator

package com.ryannorris.gwt.validation.client.validator;
 
import com.google.gwt.i18n.client.DateTimeFormat;
import com.google.gwt.user.client.ui.HasValue;
import com.ryannorris.gwt.validation.client.Validator;
 
public class DateFormatValidator implements Validator {
 
	private HasValue<String> _value;
	private DateTimeFormat _format;
 
	/**
	 * Create a validator that will verify that the given string is compliant
	 * with the pattern
	 *
	 * @param format
	 *            The format to validate against, per the specification in
	 *            {@link DateTimeFormat}
	 * @param value
	 *            The value to validate
	 */
	public DateFormatValidator(String pattern, HasValue<String> value) {
		_format = DateTimeFormat.getFormat(pattern);
	}
 
	/**
	 * Set the value to be validated
	 *
	 * @param value a string, nominally representing a date
	 */
	public void setValue(HasValue<String> value) {
		_value = value;
	}
 
	/*
	 * (non-Javadoc)
	 *
	 * @see com.ryannorris.gwt.validation.client.Validator#validate()
	 */
	@Override
	public boolean validate() {
		try {
			_format.parse(_value.getValue());
		} catch (IllegalArgumentException e) {
			// the value couldn't be parsed by the pattern, return false
			return false;
		}
 
		return true;
	}
}

So, now I have a Validator. How do I now make a widget, let’s say a simple TextBox, Validatable?

Harkon back earlier when I said I was chosing to strategize my Widgets.  That’s only partially true.  Because we’re aiming for good TDD, and hence we want to rely on dependency injection – we will in fact be decorating them as well.  We will strategize around their ability to be validated, while we will decorate them with the Validators that interest us.  This is important, as we wouldn’t want to have 20 different TextBox implementations that handle various Validation permutations.  We would rather one, decoratable TextBox that can be managed by the presenter in our MVP implementation.  So what does our initial stab at a ValidatableTextBox look like?

ValidatableTextBox

package com.ryannorris.gwt.validation.client.widget;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class ValidatableTextBox extends TextBox implements Validatable {
 
	@Override
	public boolean validate() {
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				getText());
		return validator.validate();
	}
}

Wait, you say.  This isn’t at all what you just described!  This is a text box that will only execute one validator for one date pattern! Well, you’re right.  We need to find a way to enable decoration of our TextBox in a way that can be nicely tested and extensible.  GWT makes extensive use of decorator pattern, and really strives for testability.  We see this in the various Has interfaces, which are added to classes to give them additional behaviors (such as HasText or HasClickHandler).  So, we will follow suit and create our decorator interface HasValidators.

HasValidators

public interface HasValidators {
	/**
	 * Add a validator to the decorated component
	 *
	 * @param validator The validator to be added
	 */
	public void addValidator(Validator validator);
}

And now our updated ValidatableTextBox.

package com.ryannorris.gwt.validation.client.widget;
 
import java.util.Set;
 
import com.google.gwt.user.client.ui.TextBox;
import com.ryannorris.gwt.validation.client.HasValidators;
import com.ryannorris.gwt.validation.client.Validatable;
import com.ryannorris.gwt.validation.client.Validator;
 
public class ValidatableTextBox extends TextBox implements Validatable, HasValidators {
 
	private Set _validators;
 
	@Override
	public void addValidator(Validator validator) {
		_validators.add(validator);
	}
 
	@Override
	public boolean validate() {
		boolean valid = true;
 
		for(Validator validator : _validators) {
			if(! validator.validate()) {
				valid = false;
			}
		}
 
		return valid;
	}
}

So, that’s pretty sweet. I have a collection of Validators as a member of the component – in fact I have a set of them as to ensure no Validator exists more than once on the component.  My validate method now loops through the set of validators and maintains the local state of the validation, allowing the entire validation to fail if any one Validator fails.

A highly testable passive view implementation with this component may look something like:

MySampleValidatableView

/**
 * 
 */
package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.HasKeyPressHandlers;
import com.google.gwt.user.client.ui.HasValue;
 
/**
 * @author ryan
 * 
 */
public interface MySampleValidatableView {
	/**
	 * Get the {@link HasValidators} behavior of the date box.
	 * 
	 * @return a {@link HasValidators} behavior
	 */
	public HasValidators getDateValidators();
 
	/**
	 * Get the {@link Validatable} behavior of the date box.
	 * 
	 * @return a {@link Validatable} behavior
	 */
	public Validatable getDateValidatable();
 
	/**
	 * Return the {@link HasValue} behavior of the date box. This allows us to
	 * access the value of the control.
	 * 
	 * @return a {@link HasValue} behavior
	 */
	public HasValue<String> getDate();
 
	/**
	 * Return the {@link HasKeyPressHandlers} behavior of the date box. When the
	 * user types a key in the field, we will use this event to validate the
	 * current value;
	 * 
	 * @return
	 */
	public HasKeyPressHandlers getDateKeyUp();
 
	/**
	 * Toggle the visual state of the date box so the user receives feedback
	 * when their date is valid
	 * 
	 * @param valid
	 *            Whether or not the control should reflect a valid date entry
	 *            (true) or an invalid one (false)
	 */
	public void toggleValidDateBox(boolean valid);
 
}

A lot going on here, and it’s seems verbose – but it’s not, it’s just highly testable! We need to be able to access the various behaviors of our text box so that we can test how our presenter collaborates with these behaviors.  We also need to be able to push the passive display functionality back to our view implementation so that our unit tests don’t inadvertently require a hosted environment to run.  So our presenter needs to be built to:

1. Create a DateFormatValidator with the appropriate pattern and a reference to the component holding the text value to validate;
2. Decorate the component in the view through the HasValidators behavior;
3. Execute validation whenever the user changes the value of the widget through the HasKeyPressHandlers interface;
4. Alter the visual display of the component by calling the toggleValidDateBox method.

So last but not least, our presenter:

MySamplePresenter

package com.ryannorris.gwt.validation.client;
 
import com.google.gwt.event.dom.client.KeyPressEvent;
import com.google.gwt.event.dom.client.KeyPressHandler;
import com.ryannorris.gwt.validation.client.validator.DateFormatValidator;
 
public class MySamplePresenter {
 
	public MySamplePresenter(final MySampleValidatableView view) {
 
		DateFormatValidator validator = new DateFormatValidator("mm/DD/yyyy",
				view.getDate());
		view.getDateValidators().addValidator(validator);
 
		view.getDateKeyUp().addKeyPressHandler(new KeyPressHandler() {
 
			@Override
			public void onKeyPress(KeyPressEvent event) {
				view.toggleValidDateBox(view.getDateValidatable().validate());
			}
		});
	}
}

So there you have it – a highly testable base for validation in a GWT application using MVP.

In my next post, I’ll add an event framework to validation, allowing asynchronous validation and abstraction between overall error handling and validation.

So understanding how a unit test is traceable back to a technical design on an agile team is really a key differentiation between an approach that more closely resembles cowboy coding and an approach which is relatively holistic.  No scrum master, project manager, or even architect would advocate full designs in an agile environment – instead we opt for lighter weight approaches to technical design that provide a blueprint to the code.  For many teams, this is a CRC card – a simply way of documenting the various dimensions of an object-oriented unit.

What is a CRC, and how does it relate back to tests?

Class

The core unit of code that we will refer to is the class, but this can be really any aggregation – a function library even.  This represents a loose collection of related functionality that leverages common resources, represents a concept of actions or identity, or extends existing functionality.

Responsibilities

The responsibilities of the class form it’s raison d’etre. Commonly, we can analogize responsibilities with methods, but they may be more coarse grained – and our refactoring may indeed refine the level of detail with which we understand the functional responsibilities of the class.

Collaborators

From an interestingness perspective, particularly in the context of unit testing and mocking (or stubbing), collaborators really take the cake.  When we talk about dependency injection as the core pattern of test-driven development with mocks, collaborators are indeed what we are injecting into our class to power it.

I always ask my green developers to think about these things before starting any sort of development.  Once their CRC is done and we agree on the approach, I ask them to build the programming interface, stub the implementation, and then start writing tests.  A common example I like to use when I get that befuddled look is the idea of a car.  A car has a lot of complex stuff going on that if I needed to test dependent functions of the car against, I wouldn’t want to have to concoct all of the function they provide.  For instance, the engine is a complex piece of machinery – but if I solely want to to test how my transmission reacts to engine behavior – it’s the transmission class I want to ultimately test, and it’s reactions to different engine behavior.

Let’s bring it up a level and talk about a Car as the core class.  We want our car to be able to do two things – to have two responsibilities: accelerate and stop.

public interface Car {
   int accelerate(int additionalVelocity);
 
   void setTireGrip(int gripFactor);
 
   int stop(int overDistance) throws CannotStopException;
}
 
public interface Motorable {
   int injectGasoline(int mlOfFuel);
}
 
public interface Stoppable {
   int applyBrakes() throws PadException, RotorException, WetRoadException;
}

So we’ve defined 3 interfaces. Let’s say that I’m really interested in a case where I test how the car reacts to different stopping conditions. Now, I’m demonstrating this in Java, so I’ll use syntax similar to Mockito – but the rules are the same: I’m interested in testing the requirements of the car observing the expected behavior of the brakes in those conditions. When the grip is set low, we expect the braking system to respond negatively and lock up.

We’ll also assume for now that I’ve stubbed out a skeletal implementation of the Car interface (meaning that everything throws a NotImplementedException for the time being).

@Test
public void testWetRoadConditionsWithLowFriction() {
 
   // arrange
   Stoppable s = mock(Stoppable.class);
   Motorable m = mock(Motorable.class);
 
   Car c = new CarImpl();
   c.setStopAbility(s);
   c.setMotor(m);
   c.setGripFactor(3);
 
   when(s.applyBrakes()).thenThrow(new WetRoadException());
 
   try {
      // act and assert - no real assertion, we're expecting an exception
      c.stop(100);
      fail("Should have seen a CannotStopException - there's not a lot of grip for road when road conditions are wet");
   } catch(CannotStopException e) {
      // do nothing, we're a success!
   }
}

As you can see, we’re not actually testing the brakes – we’re testing that under the given conditions that when the Stoppable interface throws an exception that prevents our car from stopping successfully that we are throw our own CannotStopException in response. The stoppable interface is a collaborator; we are not interested in this case in unit testing it, we are interested in asuming a known behavior from it, and testing how the stop() ability of the Car implementation reacts to the WetRoadException that we have stubbed.

The alternative in the past would have been to actually create the implementation of Stoppable. But having to unit test both items makes it difficult to isolate implementation issues.

So ultimately young developers, your unit tests need to test a single responsibility and not the responsibility of your collaborators. You may eventually test how the two implementations interact – that is an integration test. Ultimately though, there is more value in testing each individual unit and ensuring that the code is built to the spec of your lightweight design. Then you can isolate integration issues and write tests that specifically address finding integration problems.

While I’m still yet to try on some of the AJAX support – something that makes or breaks a web framework these days – Wicket‘s clear separation of concerns and robust architecture for MVP (right, ‘P’, as in Model-View-Presenter) has really impressed me.  Generally speaking, I have not been one to embrace convention over configuration in frameworks like RoR, simply because it seems non-scalable.  But given it’s pure focus on UI and it’s total flexibility to do whatever the hell I want with my middle tier, I’m feeling that when restricted to the presentation layer – the paradigm works.  Wicket is pretty programmer-centric, so unlike RoR, you’re not going to get off the ground without some skills or a scaffolding framework like Wicketopia, but I’m not at all convinced this isn’t a bad thing.

There are a couple of things that I could get enthusiastic with around Wicket, were someone – including myself – to improve them.

1. Documentation. Look, I hate documenting things as much as the next guy – but in as much as I’ve enjoyed the fruits of my labor in Wicket, I have not enjoyed chasing down information to all ends of the globe.  I love the fact that this is working software, and the curve isn’t too steep – but try finding stuff on form validation, or the entire concept of mounting URL paths.
2. Callbacks, anyone? So, forms in Wicket generally appear to be processed by the onSubmit() method of the Form class.  You override this in your child class of form.  This is the very object-oriented way of doing things, but it seems a touch limiting out of the box to not be able to register callbacks on this method.  My Form class exists so that I can have more than one of these per page, no doubt (take THAT ASP.NET), but I still think that I’d like to be able to actually register callback handlers as I wish in each Page, thus allowing Forms to have different behaviors dependent on where they are used.  I’m pretty sure this isn’t the 80% use case, but I still am left with only one alternative out of the box, and that’s to keep extending the class hierarchy.  It’s nice to embrace strategy pattern and all, but to me this is where we really need an observer.

   So I was able to fudge this myself by creating a FormSubmitListener interface, subclass Form and implement it’s onSubmit() to call the formSubmitted() method from my new interface, it’s own implementation registered through the constructor on my Form subclass – but I think in an MVP or MVC framework, I still would like the ability to use OOP to handle the quirks of the page lifecycle (yeah, yeah – Wicket is unmanaged), but allow observers to actually handle pseudo-user events.

These two things aside, I feel pretty at peace with Wicket as my web framework for Java projects going forward (sorry Seam).

Another note – I’m really interested in the possibilities of packaging all of the resources for the web project in the JAR file.  While WAR’s are fine for deployment, JAR’s make the application open for truly modular design.

Now to refresh my memory on getting JTA running in a pure servlet container…

This typically meant providing a real collaborator, like a PersistenceUnit in Java, so that I could test trivial operations like persisting an entity.  At the time, I challenged a manager on this:

What are we really testing?  Are we testing OUR requirement, or are we testing something we should reasonably expect Hibernate to do on the basis of our initial technology selection?

Code coverage I believe is pretty overrated.  No one cares whether or not you can prove your method to persist an entity works because the developers of Hibernate/TopLink/LINQ to SQL have already proved this through their unit tests. What you are building when you write a test that actually checks the database to see if your middleware used a pre-packaged object-relational manpping framework correctly is an integration test.  There’s certainly value to integration testing with data access layers, particularly when difficult to test components of your middleware (like stored procedures and triggers) are involved.  Saving that however, the focus of test-driven development – namely unit tests, should be on the business logic that is proprietary to your applicatiom, be it the front-end or the middle tier.

Now, suffice to say that to a good number of developers and architects this isn’t news, but if you really want to isolate the code which you wrote that is specific to your business rules and requirements – mocking frameworks are the way to go.  Particularly in an Agile project where we can readily identify certain injected dependencies (like an EntityManager, for example) as a collaborator of the class under test, your unit test is really interested in asking the question based on this interaction with this external component, how should I expect my logic to react?

In these scenarios of course, I mock or stub the EntityManager.  In the past, a fool like me would have tried to load a container within my unit test environment.  This is actually an integration test, in addition to the fact that it is costly and doesn’t add the value a truly isolated unit test which focuses on the code you wrote does.

In .Net, RhinoMocks is scalding hot with it’s supprt for mocking through lambda’s.  In JEE, I’ve fallen in love with Mockito.

So, stop worrying about how you can get JBoss running so that your CI environment can execute inside of it.  Instead, use mocks to give your code the resources it needs to vet out the conditions in your own code that you want to test.

All in all, I’m very pleased.

The m2eclipse plugin is marvelous, finally.

The day has finally come where I’m no longer fighting Eclipse to build projects using Maven, as it should be.  Maven ties far too many niceties of the world together, and to not have it as the underlying, portable build tool within the IDE has always frustrated me.  The ability to quickly start a new Maven project, apply an archetype and go is fantastic.  The fact that it doesn’t require special jazz to get a WTP project up and running is even better.

Hey look, working with my database and some JPA implementation is really easy!

…well, almost easy.  I created a project for my middleware just using the quickstart archetype.  I was just going to throw Spring on top of it and avoid spoiling the good experience so far with EJB insanity.  The next thing I wanted to do was load up my database tables as ORM classes via Hibernate.

For whatever reason, this was cool on my Mac.  Project Properties…JPA Tools…Generate entities.  This is somehow not the way to do it over in windows.  So instead I tried to add JPA as a project facet.

My first problem was that I didn’t have Hibernate set up as my default JPA provider.  Unfortunately, you can only do this through the Maven-managed dependencies.  It has to be an Eclipse user library.  So I download the Entity Manager and wire it up into Eclipse.  Add the Java Facet (somehow not a default, probably Maven’s fault), added the JPA Facet (and am told I need to add the Utility Facet, so I do that).

Further configuration required.

Ok.  So I click into this further configuration and it reasonably wants to know how I connect to the database.  Fair enough.  I do all this, and it still won’t let me apply the change.

Eventually, it appears you need to add the Java project facet first, and then and only then can I reopen the properties page and apply the JPA facet.  A frustration point, but I figured it out.

Hey, nothing special to get a project with the Wicket archetype running in WTP.

I start a separate web project and use the Wicket archetype, interested in tackling what looks to be a nice, lightweight UI package for Java (though it looks like Spring integration isn’t trivial – which is basically unacceptable these days).  I start the project, I add a server configuration, and deploy…

Holy crap, it works out of the box!

I have a ways to go, but things feel more turnkey with Eclipse than I’ve ever experienced.  I did up some JUnits with Mockito, and that was easy, indicating that if I were to set up Cruise or some other CI tool, I could quickly get going with a full Agile project.  Exciting stuff.

1. Has Java gotten boring?  If you’re a web developer, Java has always been like 6AM – too early to really be interesting, too late to convince you to go back to sleep;
2. Java’s middle tier absolutely blows anything else out of the water.  I like LINQ, but comparables like ActiveRecord for RoR or PHPYii simply can’t do the things that JPA can do;
3. IoC/DI in Java, open source or JEE, is still better than anything anyone is doing today – Castle included.

Dave points out that the “write-once, run anywhere” paradigm may have lost out to virtualization.  Call me when virtualization is native to all of the major OS’s, Dave.  Until then, the JVM is still the closest thing we have to a platform independent environment.

I’ve looked at the EE6 spec, and he’s right though.  Omitting things like Web Beans is certainly a disappointment.  The fact that we still don’t have great native dependency injection in the EE platform leaves us always falling back upon Spring.  All of these things are rather frustrating.

JavaFX – just terrible.  Adobe did it right with AIR, even if adoption is seemingly limited to hundreds of Twitter clients.

If Sun wants to start pushing the envelope instead of follwoing the leader – how about embracing a cloud computing platform through JEE?  JAX-RS is promising, but why not unify the JAX-WS and JAX-RS spec to provide a single platform for all web-based SOA?  At the very least, that would put them on par with WCF.