This discussion is archived
6 Replies Latest reply: Jan 4, 2011 12:57 PM by jschellSomeoneStoleMyAlias RSS

Mocking data objects

822589 Newbie
Currently Being Moderated
There is a public API which exposes functionality to clients. Behind that API we have implementation classes with significantly more functionality. Several of these classes are in the data model. I would like to do unit testing using mocks of these classes.

How do other organizations handle this? The best I've been able to come up with so far is to insert an additional layer of interface. Something like
// Public API released to clients
public interface DataObject {}  

// Internal API
public interface DataObjectInternal extends DataObject {} 

// Implementation classes
public class DataObjectImpl implements DataObjectInternal {}
public class DataObjectMock implements DataObjectInternal {}
I'm hoping this is a solved problem and I'm just not familiar with what's out there.
  • 1. Re: Mocking data objects
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    I am rather certain there are freeware/commercial frameworks/apis which will provide provide dynamic mocks for you.

    They basically grab the class, build a proxy, do some rules (which you provide when you start the library) and then insert themselves.

    Or so I believe.

    Seems rather complicated to me.
  • 2. Re: Mocking data objects
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    es5f wrote:
    There is a public API which exposes functionality to clients. Behind that API we have implementation classes with significantly more functionality. Several of these classes are in the data model.
    I might note that sounds a bit odd. Myself I would have a data layer api. Any other layer would use that not the data model objects but maybe that is what you meant.

    If I am building a layer and I think there is a need to mock it then I would provide that as part of the layer along with suitable pseudo functionality in the mocks. I would use interfaces to implement that.
  • 3. Re: Mocking data objects
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Although I am not a great fan of mocking complex APIs. The reason of course is that if it is complex enough that it seems difficult then getting the mock behavior correct, and keeping it up to date, requires that someone must not only do a lot of work but must verify it and get it correct.

    Which almost gets to the point where someone must test the mock.
  • 4. Re: Mocking data objects
    822589 Newbie
    Currently Being Moderated
    jschell wrote:
    I am rather certain there are freeware/commercial frameworks/apis which will provide provide dynamic mocks for you.

    They basically grab the class, build a proxy, do some rules (which you provide when you start the library) and then insert themselves.
    We have EasyMock right now, which requires interfaces to work off of. I really don't need to stub out functional classes at this point. We can't do unit testing at all, though, because our data objects are very busy and can't be stubbed out. I've just started looking at JMock. That might also be an option.
    jschell wrote:
    I might note that sounds a bit odd. Myself I would have a data layer api. Any other layer would use that not the data model objects but maybe that is what you meant.
    If I am building a layer and I think there is a need to mock it then I would provide that as part of the layer along with suitable pseudo functionality in the mocks. I would use interfaces to implement that.
    Yeah, a data layer API sure would be nice. Unfortunately, that's not currently my reality on the ground. I've got about five million lines of code directly accessing the data model implementation classes, including static factory methods, public access to member variables, etc. I'm trying to throw the first cut of an API in front of it. The problem is that there are two layers of API for these data classes: one public, which clients have access to, and one with additional functionality for internal use only. The public (for clients) API exists in the form of a set of interfaces, but the internal API is basically "cast DataObject to DataObjectImpl, and then call the methods you need on it".

    jschell wrote:
    Although I am not a great fan of mocking complex APIs. The reason of course is that if it is complex enough that it seems difficult then getting the mock behavior correct, and keeping it up to date, requires that someone must not only do a lot of work but must verify it and get it correct.

    Which almost gets to the point where someone must test the mock.
    I agree, and I should emphasise I'm not trying to stub out major parts of a complex API. I just need 2 tiers of API for the data layer, and I was wondering if my implementation implements interface X which extends interface Y was the right way to go.

    Thanks for taking the time to think about this!
  • 5. Re: Mocking data objects
    811814 Newbie
    Currently Being Moderated
    i guess its better to go for power mocking since its an interface....... its very easy... the below mentioned link may help u:http://code.google.com/p/powermock/wiki/MockPolicies
  • 6. Re: Mocking data objects
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    Bachchu wrote:
    i guess its better to go for power mocking since its an interface....... its very easy...
    Mocking complex APIs is not easy.

    And as the OP mentioned the intent was to provide the mock as part of the deliverable to client. Thus it is probably likely that it requires more flexibility than one might need in a unit test scenario.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points