-
-
Notifications
You must be signed in to change notification settings - Fork 468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve testing robustness #319
Comments
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. |
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! |
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 theAccess-Control-Allow-Headers
header, but it does not strictly perform such task. For example, if the line 105 of the filelib/index.js
were changed from:to:
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
toassert.strictEqual
in thetest/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.
The text was updated successfully, but these errors were encountered: