0

Every time I think I've found an example of this, it turns out to be that it's an example of mocking rather than testing. Note that the answer might be "don't do it that way" which I expect it might. I see lots of folks just using reflection but i was wondering if there's an easier way.

user447607
  • 5,149
  • 13
  • 33
  • 55
  • 3
    Why would you test a private method directly? The whole point of private methods is that they're *implementation details*, and you only invoke them via the public API. If you test them directly you make it *harder* to refactor, negating one of the benefits of tests. – jonrsharpe Feb 01 '18 at 16:52
  • Well we have examples of untested methods with fairly large cyclomatic complexity. In the short term, the easiest way to break them down is by adding private methods since your IDE can do that pretty easily. You could say that those need refactoring and I would agree but they have to be tested FIRST to be sure nothing is changed during a refactor. I could use protected access instead of private but why, if I don't want anyone using those methods until we have a chance to refactor? I'll read that philosophy thing below. – user447607 Feb 01 '18 at 16:58
  • Surely that's just proving my point? If you write tests to ensure that the behaviour of those large, public methods remains compliant with your requirements, it's *easier* to refactor them and demonstrate you haven't broken anything. Testing the private methods just fixes the current *implementation*, rather than validating useful *behaviour*. – jonrsharpe Feb 01 '18 at 17:01
  • Our team is under a lot of pressure, understaffed and short several of the departments that one might normally expect for an adult IT org. No prod support, no test dept, etc. etc. etc. So there are limits to what we can do because our team is doing ALL of that. – user447607 Feb 01 '18 at 17:01
  • Did I mention "no written requirements" also? Yeah. :-/ – user447607 Feb 01 '18 at 17:02
  • You might want to look into "golden master" testing, then. If there are no requirements, you can neither be sure that the current code nor the refactored (strictly: "changed", as refactoring requires you to know it still works!) code does the right thing. And *especially* if you're under a lot of pressure writing a bunch of tests that will slow down (or get thrown away in) the next refactoring step seems counter-productive. (Side note: I don't expect production support or test departments, I work in a TDD and DevOps environment.) – jonrsharpe Feb 01 '18 at 17:05
  • If you have big monolithic public methods and you wish to refactor them to be more maintainable, testable and easier to reason about: 1. Write tests that test the primary execution paths and edge cases of the monolith. 2. Refactor the monolith into private methods, applying good SOLID principles to the refactoring. 3. If you find that your private methods are cohesive then put them in a class and make them public and write tests for this class. 4. Inject the class produced from step 3 into the public methods/constructors of the monolith class from step 1. – Thomas Cook Feb 01 '18 at 17:07
  • 5. ??? 6. Sit back in awe at the awesome elegant code you've written 7. Cry as all your assumptions get thrown out the window once the code hits production – Thomas Cook Feb 01 '18 at 17:09
  • Use Jmockit. It's great for testing "untestable code" and has a Deencapsulation library useful for testing private methods – Jacob Botuck Feb 01 '18 at 17:55

2 Answers2

1

You use reflection. Alternatively, you take the approach that I take, which is that you do not test private methods explicitly and simply test them implicitly while testing public methods that consume them.

EDIT: Read this for discussion of the philosophy of testing private methods:

Should I test private methods or only public ones?

Thomas Cook
  • 4,371
  • 2
  • 25
  • 42
1

This is the PowerMockito way.

    @Test
    public void testCallPrivateMethod() throws Exception {
        Point actual = Whitebox.invokeMethod(powerMockDemo, 
            "privateMethod", new Point(11, 11));

        assertThat(actual.getX(), is(12));
        assertThat(actual.getY(), is(12));
    }

https://automationrhapsody.com/call-private-method-powermock/

user447607
  • 5,149
  • 13
  • 33
  • 55