Is it possible to do manual unit testing?

Unit testing by definition is testing of individual units where a unit is the smallest testable part of an application for example a class method in isolation. What it means is, we have to ideally test just the logic within the method and not the logic of supporting classes or libraries being used in the current method.

Now we can do this through an automated tool like junit/testNG/nunit/flexunit etc by creating stubs and even more often now mock objects which are not real objects but still mimic their behavior making it possible to unit-test functionality of a single class without actually calling underlying or collaborating classes. How is it possible manually?

The answer is NO, it is not and thus any form of manual unit testing is actually integration testing.

Should SLR be enforced

Why not? SLR (Single Responsibility Principle) part of SOLID should be enforced as part of the code and design reviews more as an adherence to guidelines rather then a rule.

There has been a lot of debate over the possibility of applying the SLR from the very start of the development and then continue to maintain it over the period where your design evolves which as I have experienced is difficult as may be acceptance to TDD or Pair Programming was to start with, but it has to be developed as a habit and the benefits will follow. It is easy to understand but can get quite tricky to implement at the very start. How it helps is

1. One reason to change for a class means complexity of the code is highly reduced
2. Code is decoupled making it easy to evolve
3. Ease for testing the code
4. Each class has a well defined and thought through purpose for its existence

As always there is a tradeoff as it might create a little bigger codebase with a lot more classes as soon as we start assigning single responsibility to each and keep on refactoring the code to do that but even then it will be much more maintainable and readable. Also it might take a little bit more time to get a hang of it and might not be as relevant for quick and dirty POCs but then those are never supposed to be deliverable working piece of software.

So no doubt an excellent principle to follow as a guideline but then is there is a limit and should not be enforced as a rule while doing a code/design review and when I say limit, there is a limit to clarity of code which you can bring in keeping the code consistent, a limit to break down the code in separate classes which share a very similar purpose, a limit to how much you want to adhere to it still developing stories at the breakneck velocity being demanded because of business reasons and a limit o isolate and encapsulate cross cutting concerns like logging or exception handling etc.

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.