test: prefer assert.match for string matching#8540
Merged
Conversation
Add a new ESLint rule `eslint-prefer-assert-match` that runs on test files and flags `assert.ok(...)` calls whose first argument is a plain string-matching expression: `startsWith`, `endsWith`, `String.prototype.match`, or `RegExp.prototype.test` (optionally prefixed with `!`). `assert.match()` / `assert.doesNotMatch()` produces much more informative failure messages than `assert.ok(false)`. The rule auto-fixes safe cases (regex literals, and string literals whose metacharacters can be escaped into a regex literal) and reports the rest without a fix. `.includes()` is intentionally not handled because it is ambiguous between String and Array. Apply the auto-fixes across the test suite. Two call sites in `packages/datadog-webpack/test/plugin.spec.js` and `integration-tests/code-origin.spec.js` are intentionally kept on `assert.ok` (with an inline `eslint-disable` comment) because their search string is a runtime value (`source`, `cwd`) and safe escaping requires `RegExp.escape`, which is only available on Node.js 24+. They can be converted once the minimum supported Node.js version is 24.
Collaborator
Author
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Contributor
Overall package sizeSelf size: 5.88 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 3.0.1 | 82.56 kB | 817.39 kB | | dc-polyfill | 0.1.11 | 25.74 kB | 25.74 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: f3feb11 | Docs | Datadog PR Page | Give us feedback! |
watson
marked this pull request as ready for review
May 19, 2026 12:10
watson
requested review from
bojbrook and
khanayan123
and removed request for
a team
May 19, 2026 12:10
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8415f93601
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
BridgeAR
previously approved these changes
May 19, 2026
BenchmarksBenchmark execution time: 2026-05-19 12:30:51 Comparing candidate commit f3feb11 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 1501 metrics, 92 unstable metrics. |
BridgeAR
approved these changes
May 19, 2026
BridgeAR
enabled auto-merge (squash)
May 19, 2026 12:24
dd-octo-sts Bot
pushed a commit
that referenced
this pull request
May 20, 2026
Add a new ESLint rule `eslint-prefer-assert-match` that runs on test files and flags `assert.ok(...)` calls whose first argument is a plain string-matching expression: `startsWith`, `endsWith`, `String.prototype.match`, or `RegExp.prototype.test` (optionally prefixed with `!`). `assert.match()` / `assert.doesNotMatch()` produces much more informative failure messages than `assert.ok(false)`. The rule auto-fixes safe cases (regex literals, and string literals whose metacharacters can be escaped into a regex literal) and reports the rest without a fix. `.includes()` is intentionally not handled because it is ambiguous between String and Array. Apply the auto-fixes across the test suite. Two call sites in `packages/datadog-webpack/test/plugin.spec.js` and `integration-tests/code-origin.spec.js` are intentionally kept on `assert.ok` (with an inline `eslint-disable` comment) because their search string is a runtime value (`source`, `cwd`) and safe escaping requires `RegExp.escape`, which is only available on Node.js 24+. They can be converted once the minimum supported Node.js version is 24.
Merged
pabloerhard
pushed a commit
that referenced
this pull request
May 20, 2026
Add a new ESLint rule `eslint-prefer-assert-match` that runs on test files and flags `assert.ok(...)` calls whose first argument is a plain string-matching expression: `startsWith`, `endsWith`, `String.prototype.match`, or `RegExp.prototype.test` (optionally prefixed with `!`). `assert.match()` / `assert.doesNotMatch()` produces much more informative failure messages than `assert.ok(false)`. The rule auto-fixes safe cases (regex literals, and string literals whose metacharacters can be escaped into a regex literal) and reports the rest without a fix. `.includes()` is intentionally not handled because it is ambiguous between String and Array. Apply the auto-fixes across the test suite. Two call sites in `packages/datadog-webpack/test/plugin.spec.js` and `integration-tests/code-origin.spec.js` are intentionally kept on `assert.ok` (with an inline `eslint-disable` comment) because their search string is a runtime value (`source`, `cwd`) and safe escaping requires `RegExp.escape`, which is only available on Node.js 24+. They can be converted once the minimum supported Node.js version is 24.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds a new custom ESLint rule,
eslint-prefer-assert-match, that runs on test files and flagsassert.ok(...)calls whose first argument is a plain string-matching expression —String.prototype.startsWith,String.prototype.endsWith,String.prototype.match, orRegExp.prototype.test(with optional!negation). The rule auto-fixes the cases it can do safely (regex literals, and string literals whose regex metacharacters can be escaped into a regex literal) and reports the rest without a fix. The auto-fix has also been applied across the existing test suite.Motivation
assert.match(string, regexp)produces much more informative failure messages thanassert.ok(string.startsWith('foo'))— the latter fails with justExpected value to be truthy: false, whileassert.matchincludes both the actual string and the regex it was tested against. Until now we relied on convention; this rule mechanically enforces it on new test code and converts the existing call sites in one pass.Additional Notes
.includes()is deliberately not handled. Across this codebase it is used about equally on strings (comment.includes("ddsh='...'")) and arrays (tags.includes('foo'),_traceBuffer.includes(...)), and without runtime type information we'd produce a lot of false positives. Easy to extend later if we want it.assert.ok(with an inline// eslint-disable-next-line eslint-rules/eslint-prefer-assert-matchcomment that explains why):packages/datadog-webpack/test/plugin.spec.jsandintegration-tests/code-origin.spec.js. In both cases the search string is a runtime value (source,cwd) that can legitimately contain regex metacharacters, and safe escaping requiresRegExp.escape, which is only available on Node.js 24+. The comments point at the rewrite we'll be able to do once our minimum supported Node version is 24.