The Artima Developer Community
Artima SuiteRunner | Why | Getting Started | Tutorial | Get Help | Discuss | Print | Email | First Page | Previous | Next
Sponsored Link

Testing Private Methods with JUnit and SuiteRunner
by Bill Venners
May 24, 2004

Page 1 of 3  >>


This article compares four different approaches to testing private methods in Java classes.

My very first use of JUnit was to build a conformance test kit for the ServiceUI API [1]. The purpose of a conformance test kit is to help ensure that alternate implementations of the same API are compatible with the API's specification. Because an API specification defines only the public interface of the API, not the API's implementation, a conformance test exercises only the public interface. In other words, a conformance test is a "black box" test. It treats the API under test as a black box, whose external interface can be seen, but whose internal implementation cannot. A conformance test of a Java API, therefore, need only access the public members of the packages and classes under test. There is no need to access package-level, protected, or private members.

When I later applied JUnit to the task of writing actual unit tests, as opposed to conformance tests, I found myself wanting to write white box tests—tests that employ knowledge of the internal implementation of the packages and classes under test. Whereas I only wanted to test public methods in my conformance tests, I wanted to write unit tests for package access and occasionally private methods as well as public methods.

Daniel Steinberg [2] showed me the common JUnit technique of using parallel source code trees, which allowed me to place test classes in the same package as the classes under test, but keep them in a different directory. This provided a clean separation of test and production code. By placing both source trees in the CLASSPATH, my test classes could access package-level methods and classes in the package under test. This still left me, however, with the problem of testing private methods.

When I asked Daniel about testing private methods, he gently suggested that I test the private methods indirectly by testing the package-access and public methods that call the private ones. This answer did not quite satisfy me, because on occasion I really did feel the urge to directly test a private method. My initial solution was to just make such private methods package access, which allowed me to test them directly with JUnit from the test classes in the same package in the parallel source tree. This worked fine, but made me feel a bit dirty somehow. Although in general I discovered that thinking about how to design interfaces so they could be easily unit tested helped me design better interfaces, in this case I felt I was making the design slightly worse to make it testable.

When I later ended up participating in the creation of what Frank Sommers, Matt Gerrans, and I eventually released as Artima SuiteRunner [3], I vowed that I would make the testing of private methods easier in SuiteRunner than it is in JUnit. But after investigating the various approaches to testing private methods, I decided not to do anything special in SuiteRunner to support testing private methods. So whether you are using JUnit or SuiteRunner, you have the same four basic approaches to testing private methods:

In this article, I will discuss these four approaches to testing private methods in Java. I will look at the advantages and disadvantages of each and attempt to shed some light on when it makes sense to use each approach.

Page 1 of 3  >>

Artima SuiteRunner | Why | Getting Started | Tutorial | Get Help | Discuss | Print | Email | First Page | Previous | Next

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use