Mocking private methods while testing

Having been working with mocking frameworks for quite sometime, mostly easymock, I always wondered some way of mocking the private methods and then testing them in isolation as I would do for any non-private methods. There has been no direct support for doing this in any of the popular mocking frameworks till now. So I was left with very few options

• Make them protected ( a hack as this is going to break my design and encapsulation), thus making it available to test in isolation. Also now I can override that method with an empty implementation while testing other public/protected methods which makes a call to this method, thus in a way trying to stub it.

• Leave them as private and have them tested as part of another method test so that it is covered as part of code coverage tool, but still has no way of testing it in isolation and also at the same time it might get executed multiple times if it is invoked from multiple methods

But recently I came across another mocking framework powermock which is sort of extension on top of easymock to allow mocking of not all private methods but also of static methods, constructors, final methods etc. It uses bytecode instrumentation and a custom classloader to do this which is OK but a little more intrusive then what I would have liked.

There is good enough documentation to depict how to mock private methods here . Also it provides some useful reflection utilities which can be used in unit testing private methods, some examples of which can be found here

DBUnit – Need for creating tables

While doing unit testing for my DAO’s with DBunit, I never really realized that I have to explicitly create tables in the in-memory database and having an XML for the test data or even a DTD to validate it is not enough. That was till I planned to use JDBC and not hibernate to implement the DAO’s.
While woking with Hibernate it was always so easy to just turn on the hibernate.hbm2ddl.auto to update as part of hibernate properties and that is it, hibernate takes care of creating the schema from the hbm files or the respective annotations. But with JDBC, we have to explicitly create the tables in the in-memory database otherwise executing the test case will throw NoSuchTableException.
The easiest way to do it, is to execute the following.

SimpleJdbcTestUtils.executeSqlScript(new SimpleJdbcTemplate(getDataSource()),
new ClassPathResource("CreateTables.sql"), true);

Obviously we can use the above if we are using spring framework.

Code Design for Testing

We all know we need to write unit test cases and in most cases we end up using a mocking framework like jmock, easymock or rmock for that, but do we really need to design our code to test? Unfortunately the answer is yes. We need to design our code in such a way so that it is easy to test (TDD or otherwise).

Here are some of the things which I keep in mind while coming up with the test enabled code.

• Always use composition rather then inheritance – This is a good practice anyway but becomes all more important when we want to test our code as there is no way to mock call to super().

 

• Avoid singletons, static and factory pattern – Instead use dependency injection framework (Guice or Spring) to inject dependencies rather then keeping the responsibility of dependency creation within the class.

 

• Avoid extreme encapsulation – Do not keep things private and final instead make it package protected. This allows text cases to override methods.