[Figleaf-developer] Mutable Integration tests (second try!)

[<sam...@ma...>]

(note: I sent the original email by accident before I'd finished writing it!)

I wrote some simple integration tests for the Mutable/Validation stuff I've been
working on (had trouble getting it into CVS, I'll try again later). Anyway, I've
created a sample Mutable object Employee, which the following requirements:

1. A name that must be non-null
2. A non-null start date that must be before the end date, if defined
3. An end date that must be after the start date, but can be null
4. A home and mobile number, at least one of which needs to be defined. Must
match the pattern XXXX-XXXXXXX
5. A non-null postcode that has to match the pattern XXX XXX
6. An age that must be above 18 and less that 65

So far validating non-null fields works, as does regexp matching for postcode
and phone numbers, and integer ranges. Next up I'll add the code to handle
object invariant validation - this will catch cross-property changes, such as
the end date being after the start date.

The EmployeeMutable class looks like this (simple code cut for the sake of brevity):
 
public class EmployeeMutable implements Mutable {
  public EmployeeMutable() {
    setupMutableImpl();
  }

  private void setupMutableSupport() {
    mutableSupport = new MutableImpl();

    //setup change handlers for properties...
    mutableSupport.addChangeHandler(NAME_PROPERTY, new ChangeHandler() {
      public void change(Object newValue) {
	name = (String) newValue;
      }
    });

    mutableSupport.addChangeHandler(START_DATE_PROPERTY, new ChangeHandler() {
      public void change(Object newValue) {
	startDate = (Date) newValue;
      }
    });

    ...

    //setup validation rules
    mutableSupport.addValidationRule(NAME_PROPERTY, new NonNullValidationRule());
    mutableSupport.addValidationRule(START_DATE_PROPERTY, new
NonNullValidationRule());

    mutableSupport.addValidationRule(POSTCODE_PROPERTY, new
NonNullValidationRule());
    mutableSupport.addValidationRule(POSTCODE_PROPERTY, new
RegexpValidationRule("[a-zA-Z0-9]{3} [a-zA-Z0-9]{3}"));
    ...
  }

  //delegates to mutableImpl
  public void commit(ChangeSet set) throws ValidationException {
    mutableSupport.commit(set);
  }

  public boolean isValidChange(ChangeSet set, ValidationCallback callback) {
    return mutableSupport.isValidChange(set, callback);
  }
}

You can now call code like this:

ChangeSet set = new ChangeSet();
set.add(new ChangeImpl("age", new Integer(18));
set.add(new ChangeImpl("name", "John Smith"));

if (employeeMutable.isValid(set, callback)) {
  employeeMutable.commit();
} else {
  showError(callback.getErrorMessage());
}

Once I've added invariant support, I'll look at creating automatic
implementations so users don't have to, in the same way as I do for
ClassDescriptor. Comments?

sam