Jest Threshold Configuration for Code Coverage

Jest's coverage option allows you to generate code coverage reports, but it doesn't inherently provide a way to fail the test suite based on coverage thresholds. This challenge asks you to create a Jest configuration that allows you to define and enforce code coverage thresholds, ensuring that your codebase maintains a certain level of test coverage. This is crucial for maintaining code quality and preventing regressions.

Problem Description

You need to create a Jest configuration object that includes a coverageThreshold property. This property should be an object where keys represent module names or globs (using * as a wildcard) and values are objects containing coverage thresholds. The threshold object should have properties statements, lines, branches, and functions, each representing a minimum percentage coverage required for that metric. If any module fails to meet these thresholds, Jest should fail the test suite.

Key Requirements:

• The configuration object must be valid Jest configuration.
• The coverageThreshold property must be present and correctly formatted.
• The configuration should allow specifying thresholds for individual modules and/or using globs to apply thresholds to groups of modules.
• The test suite should fail if any module's coverage falls below the defined thresholds.

Expected Behavior:

• When Jest runs with the provided configuration, it should generate code coverage reports.
• If any module's coverage for any of the specified metrics (statements, lines, branches, functions) falls below the configured threshold, the test suite should exit with a failure.
• If all modules meet the coverage thresholds, the test suite should pass.

Edge Cases to Consider:

• What happens if a module is not covered at all?
• How should globs be handled when matching module paths?
• What happens if a threshold is not specified for a particular metric? (Assume a default of 0% if not specified).
• How to handle cases where a module matches multiple globs? (The strictest threshold should apply).

Examples

Example 1:

Input:
{
  coverageThreshold: {
    global: {
      statements: 80,
      lines: 78,
      branches: 75,
      functions: 77,
    },
  },
}

Output: Jest runs, and the test suite fails if any module's overall coverage falls below 80% for statements, 78% for lines, 75% for branches, or 77% for functions.

Explanation: This configuration sets global thresholds for all modules.

Example 2:

Input:
{
  coverageThreshold: {
    "./src/components/*": {
      statements: 90,
      lines: 85,
    },
    "./src/utils/": {
      branches: 60,
    },
  },
}

Output: Jest runs, and the test suite fails if any module within the ./src/components/ directory has less than 90% statement coverage or 85% line coverage. Any module within ./src/utils/ must have at least 60% branch coverage. Other modules are evaluated against the global defaults (0% for unspecified metrics).

Explanation: This configuration sets thresholds for specific directories using globs.

Example 3: (Edge Case)

Input:
{
  coverageThreshold: {
    "./src/uncoveredModule.js": {
      statements: 100,
    },
  },
}

Output: Jest runs, and the test suite fails because ./src/uncoveredModule.js has 0% statement coverage, which is less than the required 100%.

Explanation: Demonstrates failure when a module has no coverage.

Constraints

• The configuration object must be a valid JavaScript object.
• Module paths and globs must be strings.
• Threshold values (statements, lines, branches, functions) must be numbers between 0 and 100 (inclusive).
• Globs should use * as the wildcard character.
• The solution should be compatible with Jest versions 25 or higher.
• The solution should not require any external dependencies beyond Jest itself.

Notes

• Consider using a library like glob to simplify glob matching if needed, but it's not strictly required. Basic string matching can be sufficient.
• Think about how to handle conflicting thresholds for the same module (e.g., a module matching multiple globs). The strictest threshold should take precedence.
• The focus is on creating the Jest configuration object, not on writing the tests themselves. You don't need to implement the actual coverage checking logic. Jest handles that internally.
• The goal is to create a configuration that, when used with Jest, will correctly enforce the specified coverage thresholds and fail the test suite when necessary.