test: avoid RegExp.prototype.test in crypto error assertion

[cruzz77]

This PR updates test/parallel/test-crypto-no-algorithm.js to align with the ongoing test cleanup and modernization work across the Node.js codebase.

As part of recent efforts, tests are being standardized to avoid using RegExp.prototype.test() directly inside assertions in favor of clearer, more explicit matching patterns. This change applies that same approach to a crypto test that validates OpenSSL error output.

What was changed

Previously:

assert(
  err.opensslErrorStack.some((msg) => expected.test(msg)),
  `did not find ${expected} in ${err.opensslErrorStack}`
);

Updated to:

assert(
  err.opensslErrorStack.some((msg) => msg.match(expected)),
  `did not find ${expected} in ${err.opensslErrorStack}`
);

Why this change

• Aligns the test with modern Node.js assertion patterns used elsewhere in the test suite
• Improves readability by expressing intent as string matching rather than invoking RegExp.prototype.test()
• Keeps assertion style consistent with recent test modernizations

Additional notes

• No functional or behavioral changes are intended
• Test logic, coverage, and failure messages remain unchanged
• All tests continue to pass

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.53%. Comparing base (15bdf38) to head (1e76a99).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #61183      +/-   ##
==========================================
- Coverage   88.53%   88.53%   -0.01%     
==========================================
  Files         703      703              
  Lines      208598   208598              
  Branches    40227    40221       -6     
==========================================
- Hits       184674   184673       -1     
+ Misses      15951    15950       -1     
- Partials     7973     7975       +2     

see 27 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Renegade334]

It's not so much that we're avoiding re.test(), but what we are avoiding is the following pattern:

assert(re.test(x), message)

since this should instead be expressed as

assert.match(x, re, message)

or simply

assert.match(x, re)

In this instance, because the expression being asserted is actually an array.some() expression, the existing pattern looks correct to my eyes.

[aduh95]

RegExp.prototype.test should always be preferred to String.prototype.match, so I don't think we should land this PR.

[cruzz77]

Thanks for the clarification. I misunderstood the scope of the pattern being avoided also given that re.test() is preferred here. I’ll close this PR.

Appreciate the review and the explanation, and looking forward to contributing further to the community.