Javalobby - Comments for "Using Logs in Unit Tests "

I ran into the same problems

digulla — Thu, 08 May 2008 05:49:18 -0400

I ran into the same problems while writing a new appender for log4j. Implementing the appender is simple - as long as you don't intend to test it. Testing log4j is insane. I was close to using reflection and setAccessible(true).

@Ronald: Seam does inject

deconcoder — Mon, 14 Apr 2008 22:59:04 -0400

@Ronald: Seam does inject the commons logger. The injection idea does make some amount of sense because you can have some control over setting up the state of the logger before it is stuffed into your class. You could make your own log factory for that I spose, but if you are doing DI, might as well do it.

@Marcos, et al: Well, in this case I was writing an aspect that logs Repository activities. Wow, I really didn't expect people would think the idea repellent. If the aspect's job is to put messages in the log, unit testing that the right messages are going in at the right levels makes sense, no?? As to the idea of a 'bad pattern' I don't get that at all. I am not taking the log message as a proof of some other thing occurring. Frankly, the bad pattern there is to only look at unit tests as proofs. You should look at them also as guarantees of desired behavior, so if someone unwires the aspect, or changes the declarations, your test fails, rather than you pushing out a release that doesn't have any logging in it. Right?

Thanks for the feedback, Guys.

There is a flaw in your

gregallen — Mon, 14 Apr 2008 05:23:25 -0400

There is a flaw in your premise, that you can test something on the basis of what it logs that is doing.

Such an approach obviously neglects to test whether the subject actually did what it claimed. e.g. if you checked for "entry" would this pass?

12:00 ACMEmodule: entry
12:00 ACMEmodule: config error, abandoning

Sounds like a dangerous pattern...

just my 2p :)

I've only used

walter laan — Mon, 14 Apr 2008 04:24:37 -0400

I've only used java.util.logging, but if would want to do something with the log in a unit test (maybe fail on a logged error?), you could just use addHandler() to do that in the unit test setup.

Logs in my Unit Tests? No,

marcos.pereira — Sun, 13 Apr 2008 23:40:46 -0400

Logs in my Unit Tests? No, thanks. Could you please show me an example where you need such thing?

Kind Regards

Well, I don't agree that

ronaldtm — Sun, 13 Apr 2008 13:07:27 -0400

Well, I don't agree that commons-logging is useless. It may be bad implemented (I've never had those classloader issues people often mention, but they may exist), but it certainly have its place.

What if Spring used LogKit, and Hibernate used Log4j, Seam used its own home-baked logging framework, and I used java.util.logging in my application? I'd have to ship two extra jars (log4j and logkit) and have four logging configuration files? What if it was a desktop application deployed by Java WebStart, and I needed to make it as small as possible?

I had this problem once, because I had to use a library that used Log4j directly, and my module was a Swing application. My luck is that the library's implementor worked by my side, and I simply asked him to change it to commons-logging, so he could still use his log4j configuration on the server (it was shared between server and clients), and I could use java.util.logging for my client. I certainly wouldn't be able to ask Gavin King to do that for me (thanks Gavin, for using commons-logging in Hibernate!).

And this idea of 'injecting' loggers is silly... So, now I have to use a container to print some error messages to the console? It may work in a server environment, since you're already stuck with some kind of container anyway, but even then, maybe your container is not my container (say, Spring, EJB, or Guice), and they don't support the same APIs for logger injection? If the did, they'd have to agree in a single common API. Maybe it would be... commons-logging's? :)