Testing Circusd logging
A new feature has been introduced that allows the Python logging configuration to be customized using an INI file, JSON file or YAML file. The path to the logging configuration file can either be supplied on the command line to circusd or as an option in the circus.ini file. See https://github.com/mozilla-services/circus/pull/706
Add new functional tests that are compatible with the current nose/tox test harness employed for existing Circus tests to verify the new configuration options are used properly.
The existing Circus tests do not cover the existing functionality for logging configuration which resides in the function circus.util.configure_logging. The coverage results published on Coveralls are misleading in this regard because the tox test harness sets an a special environment variable called TESTING which causes the test harness itself to use the same cirsus.util.configure_logging function.
Ideally the new test or tests would test the command line invocation of circusd and would verify that the correct logging configuration is used. Six example logging configuration files will be provided one each for INI, JSON and YAML formats to be supplied in the circus.ini file and one each for INI, JSON and YAML formats to be supplied on the circusd command line.
Each of these configuration files will configure the Python logging to log the circusd events to a different log file. The test can then simply verify that for a specific invocation of circusd that a log message is generated in the correct file.
Unfortunately this test approach relies on invoking circusd as a child process. This is not normally considered best-practice in a unit test environment so it presents a number of challenges:
-
Isolating the child process
-
Controlling the environment of the child process
-
Ensuring the child process terminates at the end of the test, even when the test fails or is interrupted
-
Measuring code coverage of the child process
Fortunately, functional tests can build upon each other so that test B can assume functionality tested by test A even though the test running might run the tests in any order. For the new functional tests, the base functionality of Circus will be assumed to work well and only the logging configuration will be tested. The existing test infrastructure in circus.tests.support for starting a Circus arbiter will be used to start a circusd process as a child process.
For the purposes of these tests, we distinguish between the Python process which is running the arbiter and the arbiter itself. This distinction is important because the logging configuration is process-global whereas the tests actually start and stop many different arbiters with different options.