Streamlining Automation Frameworks: How we Unified Reporters and Loggers with Winston Logger

By Eduard Dubilyer, CTO, Skipper Soft

As a CTO deeply immersed in automation, I've often faced the challenge of fragmented logging in automation frameworks. Picture this: logs scattered across the console for debugging, external tools like Report Portal for reporting, and redundant code tangled in the process. It's a setup begging for a cleaner, more streamlined solution.

That's when I decided to tackle the problem head-on. My goal? Unify the logging process into a single, efficient system using Winston Logger. Here's my story of transforming a fragmented setup into a cohesive solution that reduced redundancy and made logging smarter and easier to maintain.

The Problem: Fragmentation and Redundancy

Logging is the backbone of any robust debugging, reporting, and analytics automation framework. But when logs are scattered across multiple destinations, developers duplicate efforts to manage the same data, creating complexity and wasting valuable development time.

I knew there had to be a better way. After experimentation, I landed on a solution that blends Winston Logger with Report Portal to create a unified, elegant logging system.

My Solution: Unified Logging in 4 Simple Steps

Step 1: Building the Reporter

First, I needed a simple yet effective reporter who could communicate seamlessly with the?Report Portal. The goal was to handle both log messages and attachments in a structured way:

const reporter = {
    attach: async (pathToFile, filename, type, description) => {
        // Attach file to Report Portal
    },
    log: async (message, level) => {
        // Send log to Report Portal
    },
};        

This reporter is the bridge, ensuring logs and attachments are consistently sent to the Report Portal.

Now, let's create a logger instance with both console and report portal transports that will be used throughout the framework:

const logger = winston.createLogger({
    transports: [
        new winston.transports.Console({
            format: winston.format.combine(winston.format.colorize(), logFormat),
        }),
        new ReportTransport({
            handleExceptions: true,
        })
    ],
    exitOnError: false,
});        

Step 2: Creating a Custom Transport for Winston

To unify logging, I extended Winston with a custom transport that forwards logs to the Report Portal:

class ReportTransport extends winston.Transport {
    async log(info, callback) {
        await reporter.log(info.message, info.level);
        callback();
    }
}        

This integration was a game-changer. It allowed Winston Logger to act as a single source for console logs and external reporting, eliminating redundancy.

Step 3: Enhancing Console Readability

Logs in the console often need to be more transparent and easier to read. To fix this, I created a custom format for Winston, ensuring clean, colorful, and structured log messages:

const logFormat = winston.format.printf((info) => {
    return `${date} - ${info.level}: ${JSON.stringify(info.message, null, 4)}\n`;
});        

Logs are not just functional—they're visually appealing and easy to digest during debugging.

Step 4: Using the Logger in Tests

Integrating the unified logger into tests was seamless with the system in place. Here's an example of its usage in a Jest test:

await logger.info("Test started successfully");
await logger.warn("Warning: API is slow");        

The Results: Cleaner, Smarter Logging

By centralizing the logging process through Winston Logger and Report Portal, I achieved several key improvements:

• Reduced Code Duplication: No more redundant log handlers for different destinations.
• Consistent Log Formats: Uniform structure across all logs, whether on the console or in reports.
• Simplified Maintenance: A single logging system is much easier to maintain and extend.

Example Output

Here's how the unified logging looks in action:

Console Output

2024-12-03 - info: {
    "message": "Test started successfully"
}

2024-12-03 - warn: {
    "message": "Warning: API is slow"
}        

Report Portal Log Entry

• Level: info
• Message: Test started successfully
• Timestamp: 2024-12-03 10:45:23
• Attachments: None

[INFO] 2024-12-03 10:45:23 - Test started successfully        

What's Next?

This unified system has been an enormous step forward, but I'm considering future enhancements. Ideas include:

• Adding metrics tracking for deeper insights into system performance.
• Introducing additional logging levels for granular control.
• Exploring integration with other tools for even broader functionality.

For those tackling similar challenges, I hope this inspires you to rethink your logging setup and strive for cleaner, more intelligent solutions.

Let's continue to raise the bar for automation!

?? Have you faced similar logging challenges? How did you tackle them? Let's share ideas in the comments.

About the Author:

Eduard Dubilyer is Skipper Soft's CTO. With over 20 years of experience in software automation, he is passionate about creating scalable automation frameworks that empower teams to deliver high-quality software efficiently.