IG: Call to Print Stack Trace in junit

Should there be an "ignore in unit tests" option for CodeMaturity->Call to Print Stack Trace ?

Perhaps I'm just uninformed, but how do other people print exceptions out in unit test code? Generally do we not want to go to standard out/err? Or do we go to the trouble of making a logging facility?

Mike

5 comments
Comment actions Permalink

Michael Kirby wrote:

Should there be an "ignore in unit tests" option for CodeMaturity->Call to Print Stack Trace ?

Perhaps I'm just uninformed, but how do other people print exceptions out in unit test code? Generally do we not want to go to standard out/err? Or do we go to the trouble of making a logging facility?


Generally the exception falls all the way out of the test method and is
handled by JUnit.

If you're catching the exception, then that implies that it's expected
and you don't need to log it in test code (we have a policy of logging
all exceptions in production code whether they're expected or not).

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Michael Kirby wrote:

Should there be an "ignore in unit tests" option

for CodeMaturity->Call to Print Stack Trace ?


Perhaps I'm just uninformed, but how do other

people print exceptions out in unit test code?
Generally do we not want to go to standard out/err?
Or do we go to the trouble of making a logging
g facility?

Generally the exception falls all the way out of the
test method and is
handled by JUnit.

If you're catching the exception, then that implies
that it's expected
and you don't need to log it in test code (we have a
policy of logging
all exceptions in production code whether they're
expected or not).


hmm. I see your point.

So code like this:

protected void setup()
{
try {
something();
} catch (IOException e)
{
e.printStackTrace();
fail("This is bad");
}
}

I should probabaly let it go, rather then catching it?

Of course, how do I do that without changing the signature of setup? Or, alternatively, I can fail, but then how do I print out the exception?

Mike

0
Comment actions Permalink

Michael Kirby wrote:

hmm. I see your point.

So code like this:

protected void setup()
{
try {
something();
} catch (IOException e)
{
e.printStackTrace();
fail("This is bad");
}
}

I should probabaly let it go, rather then catching it?

Of course, how do I do that without changing the signature of setup? Or, alternatively, I can fail, but then how do I print out the exception?


The JUnit TestCase.setUp method is declared as "throws Exception" so you
can declare it on your overriding implementation.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://java.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink


As a general practice, I've avoided putting in "ignore this inspection in test code" flags. Since quality standards are so different in test code and production code, these flags would quickly multiply. I've submitted a request for a more general "use different error-checking profiles for test and product code" request, which would be my strongly preferred way of handling these cases.

--Dave Griffith

0
Comment actions Permalink


As a general practice, I've avoided putting in
"ignore this inspection in test code" flags. Since
quality standards are so different in test code and
production code, these flags would quickly multiply.
I've submitted a request for a more general "use
different error-checking profiles for test and
product code" request, which would be my strongly
preferred way of handling these cases.

--Dave Griffith



I agree. In this particular case, I think that I should just let the exception go, and all is well. I didn't realize that the setup threw exception.

Mike

0

Please sign in to leave a comment.