feat: add Mocha support - #114
Conversation
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 7f20fec | Docs | Datadog PR Page | Give us feedback! |
![datadog-prod-us1-6[bot]](https://avatars.githubusercontent.com/u/365230?s=60&v=4){kind=small}
There was a problem hiding this comment.
Custom Mocha test locations outside the default test directory fail during planning because the adapter asks Mocha to collect only its default test path before applying DDTest's filter. A project using --tests-location "spec/**/*.js" therefore receives "No test files found: test" instead of discovering its configured files.
📊 Validated against 13 scenarios · Open Bits AI session
🤖 Datadog Autotest · Commit 7f20fec · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
| if err != nil { | ||
| return nil, err | ||
| } | ||
| request, err := json.Marshal(map[string]any{"mode": "discover", "cliArgs": cliArgs}) |
There was a problem hiding this comment.
Projects using a valid custom test location cannot create a plan and cannot run Mocha through ddtest.
Assertion details
- Input: A Mocha project stores tests under spec/ and runs ddtest with --tests-location "spec/**/*.js" while no test/ directory exists.
- Expected:
Mocha discovery should use the requested DDTest test location and return spec/custom.spec.js. - Actual:
DiscoverTestFiles invokes the adapter without the custom pattern; Mocha falls back to its default spec of test and exits with "No test files found: \"test\"" before DDTest can apply its post-discovery filter.
Was this helpful? React 👍 or 👎
🤖 Datadog Autotest · What is Autotest? · @DataDog review to ask questions · Any feedback? Reach out in #autotest
![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: 7f20fec427
ℹ️ 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".
| mergedEnv := make(map[string]string) | ||
| maps.Copy(mergedEnv, m.platformEnv) | ||
| maps.Copy(mergedEnv, envMap) | ||
| return m.executor.Run(ctx, "node", []string{"--eval", mochaAdapterScript, string(request)}, mergedEnv) |
There was a problem hiding this comment.
When --command selects a Mocha executable outside the current project's module-resolution path or a wrapper that establishes execution context, this unconditionally launches a fresh node process instead. mochaCLIArgs retains only arguments following the token named mocha, while the adapter resolves mocha/package.json from process.cwd(), so the configured command is never executed and can fail to resolve Mocha, run a different version, or omit wrapper behavior. This also contradicts the documented --command behavior in docs/running.md:115-149; pass the selected command context through rather than using it only to extract flags.
Useful? React with 👍 / 👎.
1 participant
What
Add Mocha 8+ support to ddtest for JavaScript suite-level planning and execution.
The implementation uses a small embedded Node adapter to load Mocha's effective configuration and collect files without loading test modules. During execution it replaces configured
specinputs with the files assigned to the current ddtest worker while preserving other Mocha options, including shared--filesetup. It also adds framework detection, Datadog initialization handling, documentation, unit/integration coverage, and a Mocha 8/9/10/11 compatibility CI matrix.Why
Appending selected files directly to Mocha is not sufficient because Mocha combines positional files with configured
specpatterns, which can make every worker run the full suite. Mocha's discovery internals also changed across supported versions: Mocha 8 and 9 return a file array, Mocha 10+ returns a collection object, and Mocha 8 does not accept pre-parsed CLI options.This adapter handles those differences explicitly while avoiding
--dry-run, which is unavailable on Mocha 8 and loads project test/setup code during planning.E2E testing
Automated validation completed locally:
go test ./internal/framework ./internal/platform--filesetup, selected-file execution, and config-free default discoveryinternal/testoptimization/apimake lint(format, vet, and golangci-lint; 0 issues)go build -o /private/tmp/ddtest-mocha-bin main.gogit diff --checkThe existing
internal/testoptimization/apitests could not run locally because this sandbox denies the loopback port used byhttptest.NewServer. The PR's normal CI environment is not subject to that restriction.Manual scenario:
.mocharc.jsonwhosespecmatches multiple files and whosefileloads shared setup.ddtest plan --platform javascript --framework mochaand confirm only Mocha-selected test files are planned; shared setup is not partitioned.ddtest run --platform javascript --framework mochawith multiple workers.dd-trace/ci/init.