Implement Result Caching for Jest Tests

Many applications involve computationally expensive operations or slow external API calls. In a testing environment like Jest, repeatedly executing these slow operations can significantly increase test suite runtime. This challenge aims to implement a result caching mechanism to store the outcomes of such operations and reuse them across multiple test executions, dramatically speeding up your Jest tests.

Problem Description

Your task is to create a Jest setup that allows specific test functions (or suites) to cache their results. When a cached result exists for a given test, it should be returned directly without re-executing the test's logic. If no cache exists or if it's deemed stale (though for this challenge, we'll focus on simple existence), the test logic should run, and its result should be stored for future use.

Key Requirements:

• Cache Storage: Implement a mechanism to store and retrieve cached results. This could be a simple in-memory store or a file-based cache. For this challenge, an in-memory store is sufficient.
• Cache Invalidation (Implicit): For simplicity, assume the cache is considered valid as long as an entry exists. We won't implement complex invalidation logic (like timestamp-based expiration) in this initial challenge.
• Test Function Identification: Develop a way to mark specific tests or test groups as cacheable.
• Cache Key Generation: A deterministic way to generate a unique key for each cacheable test based on its identity (e.g., its name, parameters if applicable).
• Integration with Jest: The caching mechanism should seamlessly integrate with Jest's test execution flow.

Expected Behavior:

1. When a cacheable test runs for the first time, its logic will execute. The computed result will be stored in the cache.
2. On subsequent runs of the same cacheable test (with the same cache key), Jest should intercept the execution, retrieve the result from the cache, and return it immediately without running the actual test logic.
3. Non-cacheable tests should execute as normal.

Edge Cases:

• Tests that don't produce a meaningful "result" to cache (e.g., tests that only assert side effects). You should decide how to handle these, perhaps by not caching them.
• What happens if a cached test's underlying logic changes? Our simple caching won't detect this. For this challenge, focus on the caching mechanism itself.

Examples

Example 1:

Imagine a test that fetches data from a slow API.

// test.ts

// Assume this is a slow operation
async function fetchData(id: number): Promise<{ id: number; data: string }> {
  console.log(`Fetching data for ${id}...`);
  await new Promise(resolve => setTimeout(resolve, 1000)); // Simulate network latency
  return { id, data: `Data for ${id}` };
}

describe('Data Fetching', () => {
  // How do we mark this test as cacheable?
  it('should fetch data for ID 1', async () => {
    const result = await fetchData(1);
    expect(result.id).toBe(1);
    expect(result.data).toBe('Data for 1');
  });

  // How do we mark this test as cacheable?
  it('should fetch data for ID 2', async () => {
    const result = await fetchData(2);
    expect(result.id).toBe(2);
    expect(result.data).toBe('Data for 2');
  });

  // This test is not cacheable
  it('should perform a quick calculation', () => {
    expect(2 + 2).toBe(4);
  });
});

Expected Behavior on First Run (with caching enabled):

Fetching data for 1...
... (test 1 runs, logs are seen)
Fetching data for 2...
... (test 2 runs, logs are seen)
... (test 3 runs, no logs from fetchData)

Expected Behavior on Second Run (with caching enabled):

... (test 1 executes instantly, no "Fetching data for 1..." log)
... (test 2 executes instantly, no "Fetching data for 2..." log)
... (test 3 runs, no logs from fetchData)

Explanation:

The fetchData function is slow. By caching the results of the first two tests, subsequent test runs will retrieve the data instantly from the cache, skipping the actual fetchData call and the simulated network delay. The third test, not marked for caching, will execute normally.

Constraints

• The caching mechanism should be implemented using TypeScript.
• The primary focus is on demonstrating result caching within a Jest environment. We'll use an in-memory cache.
• The solution should be compatible with Jest's describe and it blocks.
• Performance improvements are the goal, so the caching overhead itself should be minimal compared to the operations being cached.
• Assume test results themselves are JSON-serializable or primitive types suitable for simple storage.

Notes

• Consider how you will identify which tests are candidates for caching. A custom Jest test.only.each or a specific naming convention might be useful.
• Think about how to generate a unique, stable key for each cached test. This key should ideally be derived from the test's name and any parameters it might be called with (e.g., in test.each).
• You might need to create a custom Jest runner or use Jest's configuration (jest.config.js) to hook into the test execution process. Alternatively, you could create helper functions that wrap your test logic.
• The goal is not to implement a full-fledged, production-ready caching solution with complex invalidation strategies, but rather to demonstrate the core concept of result caching for performance in Jest.