cors icon indicating copy to clipboard operation
cors copied to clipboard

Improve testing robustness

Open Alex-GF opened this issue 1 year ago • 2 comments

Hello,

I've been working on applying mutation testing to improve the reliability and robustness of the library, specifically focusing on how Access-Control-Allow-Headers are handled and generated. Using the LLMorpheus tool, we identified a mutation in the configuration logic that was not eliminated by the existing tests.

Issue Description

The current test suite checks the format of the allowedHeaders variable after introducing it to the Access-Control-Allow-Headers header, but it does not strictly perform such task. For example, if the line 105 of the file lib/index.js were changed from:

allowedHeaders = allowedHeaders.join(','); // .headers is an array, so turn it into a string

to:

allowedHeaders = allowedHeaders.slice(','); // .headers is an array, so turn it into a string

Then an array can be introduced to the header's value. Such Array value can then pass the test on the line 438 of test/test.js when compared to a string representation of the header values, because the loose equality check (==) in JavaScript coerces the types, which can lead to subtle bugs in production.

Proposed Change

To address this, I suggest changing the assertion method from assert.equal to assert.strictEqual in the test/test.js file, specifically at line 444. This change would ensure that the tests verify not just the value but also the exact type of the header content, preventing type coercion issues.

Impact

This improvement would make the test suite more robust and ensure that similar type-related issues are caught during the testing phase, thus improving the overall reliability of the package.

I believe that adopting stricter type checks in the tests will be beneficial for maintaining the high standards of code quality and reliability that characterizes your project.

Looking forward to the team's thoughts on this proposal.

Thank you for considering this enhancement.

Alex-GF avatar May 05 '24 20:05 Alex-GF

Hey @Alex-GF! Thanks for opening this issue. I checked it on my machine and was able to reproduce this behavior. Would you like to open a pull request with this change?

Are you planning to use the LLMorpheus tool in other repos within our organization(s)? I'm curious to explore it as well.

UlisesGascon avatar May 06 '24 05:05 UlisesGascon

Hi @UlisesGascon!

Thank you for reviewing and confirming the behavior reproduction. I have opened the pull request to address this issue following your guidelines. You can find it here.

It has been a pleasure to contribute to improving the robustness of the library. I strongly believe in the importance of maintaining high standards of quality and reliability in highly utilized software products as yours.

Regarding LLMorpheus, initially, I used it as a demo since it was recently published. However, I believe it could be a valuable tool for future projects within the organization. I am willing to explore its potential and applicability in other areas where it may be relevant.

Thanks again for your attention and support!

Alex-GF avatar May 06 '24 06:05 Alex-GF