test(idempotency): simplify wrapper & middleware tests

[dreamorosi]

Summary

Changes

Please provide a summary of what's being changed

This PR consolidates the unit tests for the makeIdempotent function wrapper and the makeHandlerIdempotent Middy.js middleware, thus reducing duplication and maintenance overhead.

More than 90% of the test cases and assertions within the tests of the two files were the exact same, resulting in a code duplication of almost 70%. This PR consolidates the tests in a single file using the the it.each() feature present in Jest.

For example, instead of having two test cases that only differ in how the handler is wrapped, we now have cases like this:

it.each([
  {
    type: 'wrapper',
  },
  { type: 'middleware' },
])(
  'does not do anything if idempotency is disabled ($type)',
  async ({ type }) => {
    // Prepare
    process.env.POWERTOOLS_IDEMPOTENCY_DISABLED = 'true';
    const handler =
      type === 'wrapper'
        ? makeIdempotent(fnSuccessfull, mockIdempotencyOptions)
        : middy(fnSuccessfull).use(
            makeHandlerIdempotent(mockIdempotencyOptions)
          );
    const saveInProgressSpy = jest.spyOn(
      mockIdempotencyOptions.persistenceStore,
      'saveInProgress'
    );
    const saveSuccessSpy = jest.spyOn(
      mockIdempotencyOptions.persistenceStore,
      'saveSuccess'
    );

    // Act
    const result = await handler(event, context);

    // Assess
    expect(result).toBe(true);
    expect(saveInProgressSpy).toHaveBeenCalledTimes(0);
    expect(saveSuccessSpy).toHaveBeenCalledTimes(0);
  }
);

In short, we now run two test cases with a discriminator (type) which instantiates the handler constant either using the function wrapper or Middy.js middleware, then carry on with the tests as normal.

The resulting test file has most of the test cases setup as described above, and only a handful of cases (<5) that are specific to one or the other method.

The logs/outputs of the tests are still distinguishable thanks to the templating used in the test case description:

Function: makeIdempotent
    ✓ handles a successful execution (wrapper) (3 ms)
    ✓ handles a successful execution (middleware) (8 ms)
    ✓ handles an execution that throws an error (wrapper) (9 ms)
    ✓ handles an execution that throws an error (middleware) (3 ms)
    ✓ thows an error if the persistence layer throws an error when saving in progress (wrapper) (1 ms)
    ✓ thows an error if the persistence layer throws an error when saving in progress (middleware) (1 ms)

Please add the issue number below, if no issue is present the PR might get blocked and not be reviewed

Issue number: closes #2918

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
27.5% Duplication on New Code

See analysis details on SonarCloud

[am29d]

Nice refactoring! Sonar still complains of code duplication and I assume this needs to be executed in the test scope or can we extract it to one function in the describe block?

      type === 'wrapper'
         ? makeIdempotent(fn, mockIdempotencyOptions)
         : middy(fn).use(makeHandlerIdempotent(mockIdempotencyOptions));
         ```

[dreamorosi]

Nice refactoring! Sonar still complains of code duplication and I assume this needs to be executed in the test scope or can we extract it to one function in the describe block?

      type === 'wrapper'
         ? makeIdempotent(fn, mockIdempotencyOptions)
         : middy(fn).use(makeHandlerIdempotent(mockIdempotencyOptions));
         ```

Thanks!

Many/most of them have different fn or different options albeit with some patterns, that's why it's run there.

We could probably create a function factory and shave off a few more lines, but that would probably require a bit more attention, mainly to avoid to hide completely the test case from the reader.

It's an area that I'd like to explore further, but for today I think we could take the win of going from ~70% to 20% duplication.