Reputation: 18720
I have following class:
public class LegacyClass()
{
public LegacyClass(final int aModeOfOperation)
{
if (aModeOfOperation == 0)
{
addSomeValues();
addSomeValues();
}
else if (aModeOfOperation == 1)
{
addSomeValues();
}
}
private void addSomeValues()
{
}
}
I want to write a unit test, which would check that
LegacyClass(0)
causes the private method addSomeValues
to be called 2 times andLegacyClass(1)
causes the private method addSomeValues
to be called once.I know that it is possible to use spy objects in Mockito/PowerMockito to count the number of private method calls, but AFAIK these approaches work only if the methods in question are called after the construction of the tested class.
Is it possible to write the unit test described above without changing the constructor of LegacyClass
?
Upvotes: 0
Views: 2571
Reputation: 42273
I don't think it's possible using mockito, as you declare the spy this way spy(new LegacyClass())
, hence your constructor is called before the object is spied. Maybe there's a way with PoweverMock but I usually discourage the use of PowerMock because no effort is put in refactoring code to a proper design.
Instead I highly recommend you to refactor your legacy code to something more testable (Test-Driven-Developement is he key here).
If you absolutely need to keep this legacy code with compatible changes but without PowerMock ; I would first instead increase the visibility level to package visible :
private void addSomeValues() { ... }
Then write a static subclass of LegacyClass
in your test, and override the addSomeValues
method that will increase a counter the call super.
public class LegacyCodeTest {
...
static class AddSomeValuesCounteringLegacyClass extends LegacyClass {
public int counter;
void addSomeValues() { counter = counter + 1; super.addSomeValues(); }
}
}
Then in your test you insatiate this class and assert the call count;
Upvotes: 1
Reputation: 6992
I think you get much better value out of unit testing if you can perform state based testing (http://blog.jayfields.com/2008/02/state-based-testing.html?m=1) on the requirements/behavior of a public methods rather than testing the number of invocation of a private methods. This might be possible in some isolation frameworks, but from the unit testing point of view I don't see much value.
Think about that some unit test, you would verify a method has been called, or a method has been called x numbers if times. These tests are verification testing and they are still valid. BUT the key factor is most of the mock object frameworks allows you to do these verification against public methods (at least in .net) . The reason is that private methods are not really important from the unit testing point of view because they internal implementation detail. Try to avoid test failures for code schematics change.
Upvotes: 4