Unit-test wrapper methods when base method is private

Question

I read this answer about unit-test a wrapper method. In following code:

public static Object methodA(Object arg) {
    if (arg == null) {
        return null;
    } else {
        return methodB();
    }
}

It looks reasonable that I don't need to test all functionality in methodB(), just test 2 cases where arg is null and not because methodB() should be tested already.

However, if methodB() is private method, I should test all functionality that methodB() will provide because according to another answer, private methods are implementation details.

The problem is, if I have 2 methods methodA1() and methodA2() and they all call methodB() like this:

public static MyObject methodA1(int x) {
    MyObject obj = new MyObject();
    obj.setX(x);
    return methodB(obj);
}

public static MyObject methodA2(int y) {
    MyObject obj = new MyObject();
    obj.setY(y);
    return methodB(obj);
}

private static MyObject methodB(MyObject obj) {
    // doSomething with obj
    return obj;
}

Should I test methodA1() and methodA2() separately? Or I can just test the private method methodB() because methodA1() and methodA2() are just wrapper methods of methodB(), so if methodB() is correctly tested, I won't need to test methodA1() and methodA2() at all.

EDIT:

I wrote separate tests for public methods at first. But the problem is, if there are many variations of the methodA, and some of the functionalities / requirements are shared in some of them, then the code of the test cases will be duplicated. That's why I wonder if I should test private method methodB().

The real problem I met is I have requirement to add a record in database, and there are many different APIs I should provide. For example, I should provide:

MyObject addMale(String name, String job);     // fill sex with "Male"
MyObject addStudent(String name, String sex);  // fill job with "Student"

And all of them checks the parameter is valid or not, fill the field that is not specified and call the private method to actually insert the record into the database, which is so called methodB().

There are many APIs like this, so if I can only test methodB() with all fields situation, maybe I can reduce the duplication of the test cases, but is that a good practice to do the unit tests like this?

EDIT2:

I know I can test private methods because I used reflection in my other test cases, and I know it can invoke private methods, too. But my question is about in this situation, testing private methods is a proper solution or not.

Answer 1

This is actually a question I've wondered about for awhile, and while it's not necessarily correct, I'll share my opinion.

The main problem is that private methods are hard to test. I did some Googling, and there some tools and techniques that let you access private methods (reflection is the main one I encountered), but they seemed a little convoluted.

But the reason you wrote a private method is because there is another method, a public method, that calls it. So while you can't directly test the private method, you can check its functionality by testing the public method which calls it.

If I were you, I would extensively test methodA1() and methodA2(), ensuring that all the functionality of methodB() is tested by the tests you run on the public methods.

Answer 2

You've received a few opinions why you should write unit tests for methodA1() and methodA2(); you've pushed back on them. You asked the question here; you are clearly looking for some justification for not writing complete unit test for them. Let's see if we can give you the answer you want. ;-)

From what you've added in your edit, it looks like you have a variation on a builder pattern. Eg)

MyObject o = new Builder().setX(1).setY(2).setZ(3).setW(4).build();

How would we test the builder?

Since the builder has 4 attributes, which could be set in any order, there would be 4! = 24 different orderings. A complete test suite would have to include:

@Test public void testXYZW() { ... }
@Test public void testXYWZ() { ... }
// ... 21 more permutations ...
@Test public void testWZYX() { ... }

But is that all? No! Some of those attributes could have default values, so we would have to test those patterns as well. Total orderings is now P(4,4)+P(4,3)+P(4,2)+P(4,1)+P(4,0) = 24+24+12+4+1 = 85 unit test.

@Test public void testXWY() { ... }
@Test public void testWY() { ... }
@Test public void testZ() { ... }
// ... 61 more permutations ordering

And this only tests each permutation of X, Y, Z, W attributes with one test value per attribute per test. It is clearly unwieldy to write an exhaustive set of tests for every possible combination and permutation.

The designer of the builder class would understand that the permutation of the attribute settings does not affect the resulting construction; writing tests for permutations of the order does not actually increase the test coverage. Tests for omitted attributes are useful, as they test the default values. Testing of different combinations of the omitted attributes again would not increase the test coverage. So, after careful thought, only two tests might be required:

@Test
public void testXYZW() {
    MyObject o = new Builder().setX(1).setY(2).setZ(3).setW(4).build();
    assertThat(o.wasBuiltProperly());
}

@Test void testDefaults() {
    MyObject o = new Builder().build();
    assertThat(o.wasBuiltProperlyFromDefaults());
}

If proper, complete testing of methodB() is being done, then you could safely get away with testing only the validation of inputs in methodA1() and methodA2().

@Test void testMethodA1Professor() {
    MyObject o = methodA1("professor");
    assertThat(o.wasBuiltProperlyWithProfessor());
}

@Test void testMethodA1WithNull() {
    MyObject o = methodA1(null);
    assertThat(o.wasBuiltProperlyWithNull());
}

Answer 3

Oftentimes, when a private method is used by multiple methods inside a class, there's a distinct concept lurking behind it. It may deserve to have its own class.

it should not be used outside of the class

There are a few ways you could extract methodB to its own class and not make it available as part of your public API :

• Nest it inside the class that uses it and give it a restricted scope

• Put it in another module at a lower level. Make that module available from your API but not from the clients.