Prev: Design Questions about static factory classes
Next: JavaSE/EE + Tomcat 6 + Windows service on 64 bit
From: Rhino on 21 May 2010 16:25
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?

--
Rhino
From: Arne Vajhøj on 21 May 2010 16:35
On 21-05-2010 16:25, 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?

Because such a method is more demo style than library style,
then I am not sure that it is suited for unit testing at all.

But if you want to do it, then just catch output and compare
it to what you expect.

Arne
From: Arne Vajhøj on 21 May 2010 16:45
On 21-05-2010 16:35, Arne Vajh�j wrote:
> On 21-05-2010 16:25, 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?
>
> Because such a method is more demo style than library style,
> then I am not sure that it is suited for unit testing at all.
>
> But if you want to do it, then just catch output and compare
> it to what you expect.

PrintStream save = System.out;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream pw = new PrintStream(baos);
System.setOut(pw);
// do something
System.setOut(save);
pw.flush();
// get output from baos.toString()

Arne
From: Patricia Shanahan on 21 May 2010 18:27
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
From: Rhino on 21 May 2010 19:26
Arne Vajh�j <arne(a)vajhoej.dk> wrote in
news:4bf6f0f5$0$285$14726298(a)news.sunsite.dk:

> On 21-05-2010 16:35, Arne Vajh�j wrote:
>> On 21-05-2010 16:25, 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?
>>
>> Because such a method is more demo style than library style,
>> then I am not sure that it is suited for unit testing at all.
>>
>> But if you want to do it, then just catch output and compare
>> it to what you expect.
>
> PrintStream save = System.out;
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> PrintStream pw = new PrintStream(baos);
> System.setOut(pw);
> // do something
> System.setOut(save);
> pw.flush();
> // get output from baos.toString()
>
> Arne

Thanks for the suggestions (and the details on how I could capture the
output)!

--
Rhino
 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Design Questions about static factory classes
Next: JavaSE/EE + Tomcat 6 + Windows service on 64 bit