Marco Tedone's blog

PODAM is finally ready - RFF (Request for Feedback)

 

As announced in one of my previous articles, I set myself to create a tool to help developers filling their POJOs with dummy data when the need arises. That tool is PODAM and I'm proud to announce that it's first 0.0.1-RC2 version has been released.

We've also created a Google group which you are kindly invited to join.

PODAM goes a long way towards helping developers in saving their time when having to fill POJOs (or graphs of POJOs) with dummy data. This tipically happens when writing unit tests or some demo code. It seems not such a big deal, but countless times I found myself descouraged when having to fill graphs of POJOs by hand, not only because the task is tedious and I could employ my time in more efficient ways but because of the code bloating. Such code, which in case of complex graphs of objects might become significant in number of lines of code, is also throw-away. Dummy data hasn't got much business value and therefore is not valuable.

PODAM solves this issue by providing developers with a one-liner:

POJO myPojo = PodamFactory.manufacturePojo(POJO.class);

That's it! For a complete example of what is and isn't possible with PODAM you are invited to visit the Podam walk-through example.

PODAM is available from Maven Central and the whole infrastructure for collaborative development is available. We've got a website with documentation (hey...what?), a Google group, JIRA to track issues, source and binary code availability, etc.

Now that I've done my part by creating a tool which hopefully is useful to many developers, I'd like to ask you to do your part, by reviewing the tool, using it, submitting feedbacks, bugs, feature requests so that I can speedily head towards the first final release.

Thank you for your help and Happy technology!

 

Git - Community Ubuntu Documentation

Git is an open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

via help.ubuntu.com

Excellent article to setup a public view of your Git repos on Ubuntu. Viewgit rocks

PODAM Journal - Added support for recursive hierarchies

Today I was talking with a colleague about Podam and he rightly made me notice that I didn't think of recursive hierarchies, e.g. a parent-child relationship. For instance a Category object might be such a hierarchical domain model object.

So I arrived at home and I added support for recursive hierarchies. Podam now supports the following POJO:

/**
 *
 */
package uk.co.jemos.podam.test.dto;

import java.io.Serializable;

/**
 * POJO to test a recursive hierarchy, like the one between parent and child
 *
 * @author mtedone
 *
 */
public class RecursivePojo implements Serializable {

    private static final long serialVersionUID = 1L;

    // ------------------->> Constants

    // ------------------->> Instance / Static variables

    /** An int field */
    private int intField;

    /** An instance to itself in a hierarchical structure */
    private RecursivePojo parent;   

    // ------------------->> Public methods

    /**
     * No-args constructor
     */
    public RecursivePojo() {
    }

    // ------------------->> Getters / Setters

    /**
     * @return the intField
     */
    public int getIntField() {
        return intField;
    }

    /**
     * @param intField
     *            the intField to set
     */
    public void setIntField(int intField) {
        this.intField = intField;
    }

    /**
     * @return the parent
     */
    public RecursivePojo getParent() {
        return parent;
    }

    /**
     * @param parent
     *            the parent to set
     */
    public void setParent(RecursivePojo parent) {
        this.parent = parent;
    }   

    // ------------------->> equals() / hashcode() / toString()

    /**
     * Constructs a <code>String</code> with all attributes in name = value
     * format.
     *
     * @return a <code>String</code> representation of this object.
     */
    @Override
    public String toString() {
        final String TAB = "    ";

        StringBuilder retValue = new StringBuilder();

        retValue.append("RecursivePojo ( ").append("intField = ")
                .append(intField).append(TAB).append("parent = ")
                .append(parent).append(TAB).append(" )");

        return retValue.toString();
    }

   

}

 

PODAM Journal - First draft implementation is ready

The first draft of PODAM is ready. Currently the framework sets the initial state of a POJO with random values. The supported types are:

• Primitive types
• Wrapper classes
• String
• arrays of objects
• arrays of primitives
• Any other object which either has a no-arg constructor or a static factory which takes no arguments

Known limitations:

• PODAM does not set the state of complex object graphs (In roadmap)
• Custom annotations as defined in my previous article are yet not supported (in roadmap)
• If a class does not expose a public, no-arg constructor, and it does not expose a public static factory which takes no arguments the attribute value is not set

You should be able to browse the Jemos Maven Repository and search for PODAM. Currently PODAM is in version 1.0.0-SNAPSHOT and the source and test code are available. 

PODAM runs under the MIT license.

Currently PODAM can fill the full state of the attached POJO (OneDimensionalTestPojo). Download OneDimensionalTestPojo

It would be nice to hear from you of any critics, suggestions, comments, issues.

Happy technology.

 

PODAM - Started implementation

I started the implementation of PODAM using TDD. I immediately identified the following strategy: if, for any given POJO, there is one or more setter method with a corresponding attribute in the POJO, this will be set according to PODAM standards.

If, however, no setters can be identified for a POJO, to have its attributes set, the POJO will need to annotate a constructor with a @PodamConstructor annotation, otherwise no attributes will be set. Such constructor then needs to set the POJO attributes to their state.

A setter is considered as such only if it adheres to JavaBeans naming standards, e.g. for a field firstName a setters MUST be named setFirstName. Names are case sensitive.

The above strategy should cover inheritance, where for instance a class MyClient extends a class Client. In case the class Client has got setters to set instance variables, and such setters are accessible from MyClient, then an instance of MyClient will be created and setters for the Client parent will be invoked. If, however, Client does not expose any setters, MyClient will need to provide a constructor which invokes the super constructor and annotate such constructor with @PodamConstructor.

The idea is that, given a POJO, PODAM creates a Map of classes vs class info for each class in the POJO hierarchy, until no further parent if found (e.g. for the Object class). For this purpose I created a new class, ClassInfo, which contains the following information:

• Class name
• A Set of declared field names (e.g. only fields declared in this class)
• A Set of setters matching field names.

So in the case above, the tool will produce a Map with:

• Client -> ClassInfo[Client, [firstName, lastName, etc], [setFirstName, setLastName, etc]]
• MyClient -> ClassInfo[MyClient, [myClientId], [setMyClientId]]

The second step (for another article) will be for the tool to retrieve all valid setters from the Map, to create an instance of the POJO being created, and to invoke all setters with appropriate values. If no setters are available, PODAM will look at a constructor annotated with @PodamConstructor. For the POJO being filled with dummy values, also private fields for which a setter method is not available will be set with dummy values, since getters might be present and used by the application. This "favour treatment", however, won't be given to superclasses, since private fields with no setters are not accessible and therefore their values cannot be set.

Happy technology.

Incompatibility between TDD, Mocking and static methods

Today I installed Jenkins CI and started building PODAM. I write all my code using TDD. The public API in PODAM offers a single method for now:

POJO myPojo = PodamFactory.createDummyPojo(POJO.class);

I decided to provide developers with a very simple-to-use API . For a complete list of PODAM requirements, please refer to my previous post.

So far I just wrote a single unit test which led to this piece of functionality:

     /**
     * Generic method which returns an instance of the given class filled with
     * dummy values
     *
     * @param <T>
     *            The type for which a filled instance is required
     * @param dto
     *            The name of the class for which an instance filled with values
     *            is required
     * @return An instance of <T> filled with dummy values
     *
     * @throws PodamMockeryException
     *             if a problem occurred while creating a POJO instance or while
     *             setting its state
     */
    public static <T> T mockDto(Class<T> dto) {

        try {
            return dto.newInstance();
        } catch (InstantiationException e) {
            throw new PodamMockeryException(
                    "An exception occurred while instantiating " + dto, e);
        } catch (IllegalAccessException e) {
            throw new PodamMockeryException(
                    "An exception occurred while instantiating " + dto, e);
        }

    }

The unit test is as follows:

@Test
    public void testSimpleDtoGraphGetsSet() {

        SimpleGraphTestPojo dto = PodamMocker.mockDto(SimpleGraphTestPojo.class);
        Assert.assertNotNull("The object cannot be null!", dto);

    }

This is obviously only the beginning but following TDD practices it was my first passing test.

I then decided to use the Jenkins CI Emma plugin to check code coverage and was really surprised when I got 50% at class level. Upon investigation the Emma plugin showed me that I didn't test the branches for InstantiationException and IllegalAccessException. Static methods cannot be mocked since these are resolved at compile time.It turns out that either one has to write an interfaced service (maybe exposed as a Singleton) or that one has to give up testing every single branch of a static method when such branch throws Exceptions difficult to reproduce.

Nowhere is written that service classes (e.g. non instantiable classes with static methods) are a bad thing; on the contrary, Effective Java 2nd Edition, in Item 4, suggests that such utility classes have their uses. As a developer, if I had to decide between:

POJO myPojo = PodamFactory.createDummyPojo(POJO.class);

and

PodamFactory factory = PodamFactoryImpl.getInstance();//Singleton

POJO myPojo = factory.createDummyPojo(POJO.class);

I'd prefer the former; the latter looks a lot of boilerplate code. 

So it turns out that if one wants to use utility classes which expose static methods, and such methods throw internallly exceptions difficult to reproduce, one has to give up full coverage. Between having 100% coverage and ugly syntax on one side and 50% coverage with easy-to-use syntax on othe other, I chose the easy syntax.

Happy technology.