One option would be to using a test log4j.xml file that has appender
filters that filter out expected error messages. Maintaining that
might not be easy.
On 6/23/07, Bob Jacobsen [EMAIL PROTECTED] wrote:
I've got a bunch of code that uses log4j for logging, and a large
number of unit tests
Bob --
Have you considered using an appender that doesn't write to any files
but simply collects all messages for later analysis?
Here's how:
1) Create an appender that simply stores all logging messages in a
static array. This appender should also provide static methods to (a)
retrieve all
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
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
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
