PODAM - Gathering requirements

As announced in my previous article I am starting a new project to provide an easy API to fill in POJOs with dummy data.

The goal of this article is to collect a first draft of requirements for PODAM. Ok, so what's needed by a tool to fill POJOs with dummy data?

1. The tool should provide a black box through a simple function: given as argument a POJO class, the function MUST return an instance of the POJO class with all its instance variables filled with data, unless otherwise stated by a custom annotation (see next point).
2. The possibility, through annotations, to customise the behaviour of such tool. For instance one might want to skip the auto-generation of data for some POJO attributes; or one might want to pilot the values assigned to a POJO: for instance on a numeric attribute the value assigned by the tool should be between 5 and 100. Other customisation could go in the direction of fine grained value assignments to properties (boolean, Date, etc)
3. The possibility to be integrated with tools such as JUnit, although PODAM should not extend JUnit but rather JUnit could make use of PODAM through composition. In this scenario, instead of invoking a Factory function which returns an instance of a POJO, one could declared a @Podam annotation on a (instance) local variable in a JUnit (or other testing framework) test and the factory method would then be invoked. 
4. For PODAM to work the POJO being set with dummy data must have a non-argument constructor

Let's try to capture the above requirements in steps. Let's start with the simplest scenario, e.g. I want a POJO with all its attributes (including its graph objects) set with some dummy values. Given the following Domain Model:

 

 A Client has got an Address and one or more BankAccounts. If I am writing a JUnit test for a service which uses the Client POJO, I'd like PODAM to offer something like this:

public class ClientServiceUnitTest {

  @JUnit

  public void testClientService() throws Exception {

    ClientService service = EasyMock.createMock(ClientService.class);

    Client clientDto = PodamFactory.createDummy(Client.class);

    service.persistClient(clientDto);

    EasyMock.expectLastCall();

    //Etc. Replay and Mock validation

  }

}

PodamFactory should return a Client POJO whose primitive types attributes are filled with values but also whose graphed objects are filled with data. So the client will have an address object filled with dummy data and a collection of one or more bank accounts.

Now let's look at some more interesting scenarios. Let's say that I wanted a Client POJO filled with data but I wanted the address attribute to be skipped. I could write something like the following:

//Imports omitted

public class Client implements Serializable {

  private String firstName;

  private String lastName;

  @Podam(skip=true)  private Address address;

  private List<BankAccount> bankAccounts;

  //Constructors, getters/setters, equals/hashcode and toString methods omitted for brevity

}

 I could use a @Podam annotation with boolean attribute skip = true to indicate that a certain attribute should not be filled by PODAM. Of course for graphed objects to be filled with dummy data, these should be PODAM-compliant (e.g. have a no-arguments constructor).

Another scenario could be that I wanted to specify exactly how many bank accounts I wanted. using the same class as before I could have:

//Imports omitted

public class Client implements Serializable {

  private String firstName;

  private String lastName; 

  private Address address;

  @Podam(nbrElements=5)

  private List<BankAccount> bankAccounts;

  //Constructors, getters/setters, equals/hashcode and toString methods omitted for brevity

}

By using the nbrElements attribute I could instruct PODAM on how many elements in the list I'd like to be filled with dummy data. So it seems that a @Podam annotation is emerging from the initial requirements. The question here is whether such annotation (which belongs mainly to the testing world) would be acceptable in a production POJO code. My view is that annotations in general are innocuous and that the benefits of having fine grained control over auto-generated dummy data during testing outweighs the cons of having a "test related" import in our code.

Let's see if I can define some attributes of a @Podam annotation.

• skip. (Boolean). It instructs the tool to skip the auto-generation of dummy data for the annotated attribute. The default is false. 
• value. (String). It asks the tool to assign exactly the value specified in the attribute. The default is a blank String.
• minValue. (Numeric). It requires the tool to assign a numeric value to the annotated attribute which should not be less than the value defined in the annotation.
• maxValue. (Numeric). Similar to minValue except that the value assigned to the annotated attribute should not be greater than the value indicated by the annotation. The default is the maximum value for the type of the annotated attribute.
• nbrElements. In case of a Collection, the number of elements the tool should create with dummy values. The default is 1.
• length. (Numeric). The length of the dummy string value assigned to the annotated attribute. The default can be an arbitrary number, such as 5, 10, 20, etc.

So far these are the attributes I could think of. What do you think folks?

Happy technology.