How to unit test a class which extends/inherits a 3rd party class

Question

I have created a new class which extends a 3rd party abstract class. The new class calls methods in the abstract class. The problem I have is when trying to write the unit test, I'm not sure how to write a test as I would not know the exact details the 3rd party class requires.

The AbstractDecoratorMapper below is a SiteMesh specific class which I have to extend for SiteMesh to work correctly. As far as I can tell from the documentation I can't use composition.

public final class PartnerDecoratorMapper extends AbstractDecoratorMapper {

    @Override
    public void init(Config config, Properties properties, DecoratorMapper parent) throws InstantiationException {
        super.init(config, properties, parent);
    }

    @Override
    public Decorator getDecorator(HttpServletRequest request, Page page) {
        if (super.getDecorator(request, page).getName().equalsIgnoreCase("default")) {
            return getNamedDecorator(request, "externalPartnerDefault");
        }
        return super.getDecorator(request, page);
    }
}

I use JMock if there is anything this tool can do to help.

Francisco Spaeth · Answer 1 · 2012-06-11T10:05:32.883

4

You don't need to know details from 3rd party libs... you just need to mock them returning something you expect from them.

In the case you are inheriting it you could setup the class as it will be used on production and invoke the methods that should be invoked in regular uses. All that you need to check is if the result is as you expect. (you don't need to know exactly how the 3rd party classes works on the test).

In order to check if all code you implemented was executed you can use a plugin to check the coverage like eclemma - http://www.eclemma.org/ )

edited Jun 11 '12 at 10:05

answered Jun 11 '12 at 10:00

Francisco Spaeth

23,493
7
67
106

In my test I would need to call the init() method with the 3 parameters and I don't really know what they are as SiteMesh creates them for each page request. So in my test would I still need to create these parameters until the test works so its just a matter of trial and error? – Ilyas Patel Jun 11 '12 at 10:31
If you just want to test your piece of code, you could instantiate it with a few acceptable parameters and override in your test (implementation descending your class specific for your test in which you will override some methods that should return an expected value) the methods your code depends on. – Francisco Spaeth Jun 11 '12 at 10:46

score 3 · Answer 2 · edited May 23 '17 at 11:44

3

With JMock, you can't to the best of my knowledge mock calls to a superclass of the class under test.

The answers to this related question may be useful, but the main answer is to switch to a mocking framework (JMockit is suggested) that does support this.

edited May 23 '17 at 11:44

Community

1
1

answered Jun 11 '12 at 11:20

Don Roby

40,677
6
91
113

score 2 · Accepted Answer · edited Jun 24 '13 at 18:44

There are two things you might be asking. I'll try to answer both.

Possible Question 1) How do I test my Additional Functionality?

Possible Question 2) How do I test the the combined functionality is appropriate?

Let me start with Question1.

I would suggest a simple peel. There is a video of the technique here: http://www.youtube.com/watch?v=p0tILwRZH5Q (the video is c# but basically identical in java)

which would mean you would have the following code afterwards

@Override
public Decorator getDecorator(HttpServletRequest request, Page page) {
    Decorator d = super.getDecorator(request, page);
    return getResolvedDecorator(d, d.getName(), request);

}
public Decorator getResolvedDecorator(Decorator current, String name, HttpServletRequest request) {
    if (name.equalsIgnoreCase("default")) {
        return getNamedDecorator(request, "externalPartnerDefault");
    }
    return current;
}

Now you can test this with a call like

assertEquals(expected, new PartnerDecoratorMapper().getResolvedDecorator(null, "default", MockHttpServletRequest);

I would suggest possibly removing data from HttpServletRequest as well, to make the testing & intent clearer.

Note: this has the added performance benefit that the call to super.getDecorator() only occurs once, since the result is cached.

Additional Note: It is also worth noting that the override of init() is unneeded, and doesn't actually do anything.

Question 2: This is a harder question, as you don't state what the desired behavior is. I am assuming this is a factory pattern, so most likely it would work in some manner like

(I have no idea what this above chart should contain or look like) Once you have this behavior then the test to ensure it would be rather straight forward.

Happy Testing, Llewellyn

Thank you for spending time on this answer. I made a slight mistake but in your new method (getResolvedDecorator), the call to getNamedDecorator() would be super.getNamedDecorator(). Would this still change your implementation as this calls the 3rd party extended class? — Ilyas Patel, Jun 11 '12 at 14:20
you are welcome. the answer depends on how hard it is to setup and call the getNamedDecorator(). If this is hard, I tend to want to be able to avoid it, but overall, you still want to focus on the given the page & url request charactoristics of a,b,c expect a Decorator of type d. — llewellyn falco, Jun 12 '12 at 13:50
and with a bit of refactoring your tests should come to look like those two lines — llewellyn falco, Jun 12 '12 at 13:55

score 1 · Answer 4 · answered Jun 11 '12 at 12:24

as I would not know the exact details the 3rd party class requires

Testing, of any kind, compares what something actually does with what it ought to do. You can not test until you know what something ought to do: "what the 3rd part class requires".

And how can you make any reasonable attempt to write your derived class if you do not know what the base class requires? What does the API documentation for the class you are extending say?

Is the problem perhaps that there is no such API documentation, or it is uninformative? It might be that, although the class is not final, it is not really intended to be used as a base class. Either of those indicate a poorly designed API, and suggest you should not bother using it

Or is the critical difficulty that you do not know the exact details? That might be a flaw in your approach: typically you can not and must not make assumptions about exact details. Your code should conform to the documented API, and you should not assume anything that is not stated in the documented API. That can mean that you can not know when your Template Methods might be called or what the values will be passed to them. If the base class communicates with your Template Methods by passing objects that are declared to implement an interface or a non-final class (that is, their type but not their class is specified), you can not know what class those objects will have.

How to unit test a class which extends/inherits a 3rd party class

4 Answers4