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.
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.
Jake
At 12:29 AM 6/24/2007, you wrote:
>At 10:58 PM -0500 6/23/07, Steve Souza wrote:
>>JAMon can keep aggregate stats for your messages
>>(error/fatal/warn/info/debug and more), and you could test to ensure errors
>>did not occur with JUNit against the jamon data. for more on jamon you can
>>go to www.jamonapi.com. For more on how jamon works with log4j (no code
>>changes are required. Just use the JAMonAppender), go to
>>http://jamonapi.sourceforge.net/log4j_jamonappender.html
>
>Thanks for the suggestion.
>
>JAMon looks like it might be part of the solution. We can probably
>use it to check for _unexpected_ errors (e.g. real errors), but I
>don't (yet) see how to use it to suppress _expected_ errors that
>happen as part of the testing.
>
>I'll read some more to try to figure that out.
>
>Thanks again!
>
>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]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
