Testing the Extended Logger

The next set of tests are for the ExtendedLogger from my article Custom Configuring Java Apps: Extending log4j. The test class (ExtendedLoggerTest) is in ExtendedLoggerTest.java. The ExtendedLogger works like a standard log4j logger, but it also supports a printf() file variant for all the log methods. I'm testing that functionality by actually logging something to a known log file, then reading the file to make sure that the logged string is what I expected.

Most of the work is in the setup() method at the top of the file, which creates a temporary file into which we'll log, then reconfigures log4j to log to that file rather than to it's normal target file.

The extended logger gets the location of the target log file from it's log4j.properties file, the location of which is defined in the CONFIG environment. As was the case with the Places tests we looked at a moment ago, I'm spying on the System class and telling it to return the location of the log4j.properties file created in setup() rather than the normal properties file. This way, all logging will go to the temporary file created at the top of setup().

The tests just log something, read back the logged text from the temporary file we created, and succeed if they've found the expected log message.

Note that here, as was the case earlier, I'm testing the ExtendedLogger as a black box. The object under test is just working in the normal way, but I'm using the neighbors to control its behavior so that I can test it.

Testing Configurations

Just to round out the set, I've also included the test file for the file-based configuration system described in my article Type-Safe File-Based Configuration (ConfigurationTest in ConfigurationsTest.java).

There are no new testing principles demonstrated here, so I'll just give you the file to read without much in the way of comment. ConfigurationsTest is just a straight JUnit test, with no mocking at all, so is pretty boring. I'm actually testing Configurations.Support object, but to do that, I have to implementing a fake configuration (TestConfiguration in TestConfiguration.java). I use the Configuations.Support.createConfigFileUsingDefaults() method to create physical configuration file (on the disk) that matches the defined in Java.

The one interesting method is createPropertiesFile() at the top of ConfigurationsTest.java. calls Configuations.Support.createConfigFileUsingDefaults() to create the properties file in memory by creating to a StringWriter rather than a FileWriter. It then goes through the file, one line at a time, replacing all strings that match a regular-expression argument with a replacement string. This way, the various tests can effectively replace one or more key=value pairs in the generated files with the custom strings that they need to test whatever they're testing.

For example, the createPropertiesFile("intBound.*", "intBound=0") call in the following test replaces the legal intBound=2 statement in the properties file with the string intBound=0 (which is out of bounds). The TestConfiguration.intBound.value() call will then force the out-of-bounds value to be read, and the test succeeds when the resulting ConfigurationError is thrown at file-load time.

    @Test( expected=ConfigurationError.class )
    public void detectValueTooLow() throws IOException
    {   //...

        createPropertiesFile("intBound.*", "intBound=0" );
        TestConfiguration.reset();                  // reset to force reload on next access
        TestConfiguration.intBound.value();         // load the bogus value.
    }

The other tests are similar. They either make sure that the expected values are the ones that are actually loaded and that the values are the right type and are in range, or that the load fails as expected when something's wrong.

Wrapping Up

So, that's a few basic tests that demonstrate the core principle of testing an object as a black box. This sort of testing wouldn't be possible if the object had an inappropriate interface (lots of getters and setters, for example) because the internal state of the object would be too easy to change, so we couldn't test every possible behavior. More to the point, these tests won't have to be modified if I need to modify the objects that I'm testing, so they should remain useful for a long time. Next month, we'll move on to more interesting uses of mocks.