Testing Log Level Control at Runtime

In this lesson, you will learn how to verify that your Node.js application correctly propagates dynamic log-level changes across multiple modules at runtime.

When managing distributed services, you often need to increase log verbosity (e.g., switching from info to debug) on the fly to diagnose production issues. Testing this requires more than just checking a single setter; you must ensure that every module, especially those using separate logger instances or shared dependencies, honors the new configuration without requiring a process restart.

The Challenge of Distributed Loggers

In a modular architecture, developers often instantiate loggers locally within files. If your application logic relies on a global configuration object, you must verify that changing this object triggers an immediate update in every active module.

To test this, your test suite should:

1. Initialize multiple modules that output logs via a shared logging utility.
2. Capture the output (e.g., using a stream or a mock logger) to verify the initial state.
3. Trigger the runtime change (often via an internal configuration endpoint).
4. Assert that the entire system—not just the main module—filters or allows logs accordingly.

Implementation Pattern

Consider a test scenario using sinon to track calls to your logger:

const logger = require('./logger'); // Shared instance
const moduleA = require('./moduleA');
const moduleB = require('./moduleB');

test('should propagate log level change to all modules', () => {
  const spy = sinon.spy(process.stdout, 'write');
  
  // 1. Set to ERROR
  logger.setLevel('error');
  moduleA.doWork(); // Should not log 'debug'
  moduleB.doWork();
  assert(spy.notCalled);

  // 2. Dynamically change to DEBUG
  logger.setLevel('debug');
  moduleA.doWork();
  moduleB.doWork();
  assert(spy.calledTwice); // Verify both modules responded
});

The critical aspect here is ensuring your logging abstraction uses a live reference to the configuration rather than caching the initial value upon module instantiation. By forcing your test to monitor multiple entry points, you validate that your "hot-swapping" configuration logic is correctly linked throughout the dependency tree, preventing "zombie" modules that remain stuck at the original log level.

Key Takeaway: Testing dynamic log levels requires verifying that all system modules observe the updated configuration simultaneously, ensuring no part of your architecture is left operating on stale state.