This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Testing and the fly likes junit test for log4j Filter method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "junit test for log4j Filter method" Watch "junit test for log4j Filter method" New topic
Author

junit test for log4j Filter method

Kamal Ahmed
Ranch Hand

Joined: Feb 15, 2005
Posts: 91
Hi,

I have a junit test:


For the method:



any ideas on how can I test more using regex.

Thanks,
-Kamal.

EDIT: I wrapped your code snippets between UBB CODE tags in order to make it readable
[ January 25, 2006: Message edited by: Lasse Koskela ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Kamal Ahmed:
any ideas on how can I test more using regex.

I'm afraid I don't understand what you mean by "test more using regex". Could you be more specific?

In any case, a couple of notes:

1) That's a constructor, not a method.

2) The test method you've posted is actually testing three different inputs to the constructor -- I'd rather see those as separate test methods with descriptive names:



Note how I've had to name the tests with "...AndDefault", "...AndTrue" and "...AndFalse" because I had no idea based on your test code what the purpose of that boolean argument is! When you write your tests with the next guy in mind, you'll eventually thank yourself for being so thoughtful. Readability is crucial in test code just as it is in production code.

Furthermore, you're doing a lot of similar things in each of the methods which is a clear hint for doing some refactoring to remove duplication...


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Kamal Ahmed
Ranch Hand

Joined: Feb 15, 2005
Posts: 91
Lasse,

Thank you very much for your valuable input. I will make sure that the problem is more readable and understandable next time.

1. You are correct, this is a constructor
2. By using regex, i meant to test various regex's as inputs, and these would test the names of Loggers
3. This constructor is based on log4j , and this is an API i am testing based on log4j
4. I am not entirely sure what the actual objective is, here is some clue:

Once you get the logger, target, you should be able to just
target.error( �here�s my test string� );
The logger will create the logging event and forward it to your appender.
The kind of thing I had in mind was to define two appenders that use this filter. One appender calls the filter and uses JUnit assertTrue on the result � expecting the filter to pass the message. The other appender will be exactly the same except it will use assertFalse � expecting the filter to reject the message.
You can use the appenders with a couple of string arrays containing variations on logger names. An array of matchers would have logger names that should match your regex. An array of non-matchers would have logger names that shouldn�t. Then you can loop through each array, get a logger and log a message.
Attach the first appender to the root logger and then log the matching messages. If the filter handles all the matches properly, all the assertTrue()s will be satisfied. Then remove that appender and attach the other and log the non-matching messages.
This type of arrangement ought to support several different tests with different filter configurations.
You may be able to do this with one appender, and have it use either assertTrue or assertFalse, depending on a configuration flag.

Thanks,
-Kamal.
[ January 25, 2006: Message edited by: Kamal Ahmed ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I still don't get it. If you're testing the filter, why create appenders? Why not just invoke the filter directly? Maybe I'd understand if I saw what's inside the WmLoggerFilter.
Kamal Ahmed
Ranch Hand

Joined: Feb 15, 2005
Posts: 91
Lasse,

You could be right, i wish i could give you more information on what the requirement actually is, but i am learning about it as i go along. Anyway, here is WmLoggerFilter

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Ok. Now I see. You have an implementation of Log4J's abstract Filter class that you'd like to unit test.

Firstly, when looking at the interface specified by the Filter class, we can determine that the essential behavior (and thus the behavior we should probably focus on) is the "decide()" method.

The setTargetString() and setAcceptMatch() methods aren't even used outside of the class (only from the constructor) so perhaps they should be made private? At the very least, the getters for those attributes are unnecessary since there's usually little sense in testing that "the getter returns the correct value after the setter has been called". In some cases, perhaps, but in the vast majority of cases it doesn't.

I would just delete the activateOptions() method since it's doing nothing except invoking the parent class's implementation. I presume you left it there as a reminder of such method's existence?

Oh, and I'd also recommend not making methods final unless you have a good reason. Final methods are a major pain in the ass considering testability--because they cannot be overridden.

After a couple of quick refactorings, this is what I'd come up with for the production code (without knowing anything about implementing Log4J Filters, e.g. whether those public setters are needed in order to configure the logger from a configuration file or something):

And the test code might look like this:
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: junit test for log4j Filter method