At 7:13 AM -0500 6/24/07, Jacob Kjome wrote:
I'm not sure whether I'm interpreting your request correctly, but I
think you are saying that some of your non-JUnit code might spit out
errors by the simple fact that you are testing "expected failures"
by intentionally putting objects in a state where they should fail
to make sure they do fail under conditions that you expect them to.
The problem, then, is that this extra logging is confusing when the
test actually passed.
Right! A class that's being tested (not the JUnit test class itself)
is being given input that triggers a warning or error message. I'd
like to have the JUnit code actually check that those messages happen
, but much more important I'd like to have the "expected" messages
_not_ show up in the log output, so that "unexpected" messages (which
indicate a new fault in the code, something very important to know
about) _do_ show up.
In other words, I'd like the tests to have a clean output log, with
new messages able to be logged, and "expected" messages supporessed.
What I usually do to solve this is name my test loggers differently
than my regular loggers. Specifically, I prefix all test loggers
(those in my JUnit test classes) with "test.". For instance,
"test.com.mycompany.MyUnitTest". Now you can change your config to
log "test.com.mycompany" to a separate appender, setting additivity
to "false". If a unit test failed, then you can log to this logger
and it will show up in the test.log file. If it was an expected
failure, you wouldn't log it in the unit test (at least not at the
"error" level, maybe "debug" or "info" levels) and nothing would
show up in test.log for this case. Instead, logging for your
regular, non-unit-test classes, would go to another log file, which
seems like what you want. You can log everything to your other log
file, including output from your unit test loggers in order to see
the logging around expected failures in context, just to make sure
you set up your expectations properly.
For the purposes of those looking to see if there were any unit test
failures, one can just look at test.log, which should usually be
mostly empty. If it isn't, then you can look at the specific error
and find it in context in the other log file containing all logging.
I don't understand how this works. The original code is still using
the same logger object as it does in normal operation; that's where
the messages I'm interesting in seeing/suppressing come from.
The way we have this set up, each class has it's own logger, which
allows us fine granularity when debugging. But at the class level,
some messages may still be "expected" and "unexpected", so just
filtering at that level isn't going to do it entirely
One of the root causes of the problem is that our code tends to log
error or warning messages and proceed when it sees something
inconsistent, rather than throwing exceptions. Exceptions we would
detect in the JUnit code, and that would make all this much easier.
But we've got what we've got, and though we'll be moving more toward
exceptions in the future, now I've got to find a way to deal with
hundreds of error messages.
Bob
--
Bob Jacobsen, UC Berkeley
[EMAIL PROTECTED] +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
