I'm an Agile and Lean Strategist specialised in coaching and managing the transformation of IT departments, from startups to enterprise-scale organisations, to highly efficient, productive and energised environments. I also have experience as senior development manager and architecture governance in large enterprises, especially in the finance sector. Marco is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

PODAM - Gathering Requirements

  • submit to reddit

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:


PODAM Example 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 {


public void testClientService() throws Exception {

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

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



//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;


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?


From http://tedone.typepad.com/blog/2011/03/podam-gathering-requirements.html

Published at DZone with permission of Marco Tedone, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



jmwap wap replied on Thu, 2011/03/31 - 3:06am

you might want to look at http://stackoverflow.com/questions/838616/way-to-initialize-a-javabean-to-random-values

Marco Tedone replied on Thu, 2011/03/31 - 7:05am in response to: jmwap wap

Hi, Thank you for the pointers. I had a look at what has been written at the post you indicated but I couldn't find anything to satisfy my requirements.

The main purpose of the Functional Java library is not that of filling POJOs with dummy values but rather a library to apply functional programming concepts to Java. So the fact that the Arbitrary class could be used to generate some random values is useful but could only be used when filling POJOs data. Additionally it looks like one needs to know the structure of the POJO to be filled.

The main goal of PODAM is to provide developers with a way to fill their POJOs with dummy data without asking developers to know the POJO structure; additionally PODAM wants to provide developers with the possibility to use annotations to customise the data with which POJOs are being initialised. 

The BeanIterator reply was just not relevant to the question. Commons Beanutils does not provide what I am looking for although it would have been nice if it did. 

Thank you for your pointers though, this is exactly the kind of help I'm looking for in the community. I wish somebody could tell me: "Hey Marco, there is this library which already does that. Why reinventing the wheel?". 




Shoaib Almas replied on Sat, 2012/08/25 - 6:01am

when PODEM creates a test objects, should all created instances be equal, or would they simply be equivalent with respect to the @Podam instructions. In other words if you have @minValue = 5 and @maxValue on some field, would all instances of that class contain that field with the same value (between 5 and 100), or would they be various values between 5 and 100

Java Forum

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.