Re: Another JUnit scenario

From:

Patricia Shanahan <pats@acm.org>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 21 May 2010 15:27:59 -0700

Message-ID:

<YfqdnWRcetdwlWrWnZ2dnUVZ_jmdnZ2d@earthlink.com>

Rhino wrote:

What is a good JUnit test for a method that takes no input parameters,
throws no exceptions, and returns no values but only writes information to
a console?

In addition to the getLocales() method which we're discussing in another
thread, I have a displayLocales() method which begins by calling getLocales
(), then writes the information it got from getLocales() to the console.

I'm at a loss in trying to think of something to test in a JUnit test for
this method.

Is there some way to prove that the console was written to? Is there some
way to intercept the output to be sure that the right things were written?
Or that at least the right number of lines was written and a few of the key
Locales appeared on the console? Or is none of that necessary for a method
with these characteristics?

This sort of thing illustrates a somewhat subtle advantage of test
driven design. There are often small differences in an interface design
that make all the difference in how easy it is to test. Test driven
design naturally leads to a preference for designs that can be tested
over designs that are harder to test.

For example, many output methods could be written to take a PrintWriter
or PrintStream parameter. Methods written that way are easy to test by
giving them a PrintWriter based on a StringWriter or a PrintStream based
on a ByteArrayOutputStream.

You still need a system level test procedure that checks that output is
going to the right destination, but that test can even be manual, and
does not need to deal with the unit test level details.

Writing the tests after defining the method you are stuck with
workarounds such as temporarily replacing System.out.

Patricia