Repository navigation
mxcli test <dir> ignores test files in subfolders and reports "Found 0 test(s)" #1363
Description
What happens
With suites grouped per module, a common layout for a multi-module app, a run over the parent folder finds nothing:
tests/
Sales/
math.test.mdl
$ mxcli test tests --list
Found 0 test(s):
$ mxcli test tests/Sales --list
Found 1 test(s):
test_1: adds two numbers
A real run over tests then fails with "no tests found". Nothing hints that the files are one level down, so it reads as if the suites were broken. To work around it, you have to pass every leaf folder separately (mxcli test tests/Sales tests/Orders …).
Reproduced with mxcli v0.24.0 on Windows 11; no project is needed for --list. The code is unchanged on main.
Cause
testrunner.ParseTestDir (cmd/mxcli/testrunner/parser.go) reads one level with os.ReadDir and skips every directory entry (if e.IsDir() { continue }).
Suggested fix
Walk the folder (filepath.WalkDir), collecting *.test.mdl / *.test.md at any depth in a stable (lexical) order, and skipping hidden directories. The per-file error handling (FileErrors) stays as it is. Happy to send the PR.
Activity
github-actions commentedon Oct 9, 2026
Issue Triage
Summary:
mxcli test <dir>does not discover test files located in sub‑directories, reporting “Found 0 test(s)” even when tests exist deeper in the tree.Checklist (bug report)
mxcli test tests --listto list tests in a multi‑module layoutMissing information:
mxcli diag --bundle(or at least the relevant log output) to help reproduce the issue.Could you please add the Mendix version and attach the diagnostic bundle/log? Thanks!
Automated triage via OpenRouter — workflow source
fix: mxcli test finds test files in subfolders (closes mendixlabs#1363)
AlvinnYeo commentedon Oct 14, 2026
REPO: mendixlabs/mxcli
WHY A COMMENT: #1363 (open) reports exactly this:
mxcli test <dir>reads only that folder's own files. This comment adds a second platform and version, plus the part that cost us: a 0-test run looks green.Same on mxcli v0.25.0, macOS arm64, Mendix 11.14.0 project (MPR v2).
Our suites are in
tests/unit/(96 tests in that folder, plus a positive control one level down intests/unit/_control/). The command in our project instructions wasmxcli test tests/ -p App.mpr --local. It ran nothing:The bigger problem was not the missing subfolders. A run that finds 0 tests was easy to read as "the suite passed". It got into a build plan row as a test step before anyone counted. Two requests, in order of value:
0 tests found in tests/ (subdirectories are not searched: unit/, …), and exit non-zero on a real (non--list) run that finds 0 tests. A pipeline should never see a 0-test run as a pass.filepath.WalkDir, lexical order). Skipping folders that start with_or.would also keep a deliberate positive-control folder like ours out of the default run. We rely on that today by accident.Workaround until then: pass the leaf folder (
tests/unit/) and fail the step if the reported count is 0.Merge pull request #1363 from ako/fix/1472-check-reference-kinds
stagknee commentedon Oct 15, 2026
Thanks for the second report. #1368 now covers both of your points:
0-test runs. A real run (not
--list) that finds no tests already exits 1, and has done since v0.20. Checked on v0.26.0:The silent one was
--list: it printedFound 0 test(s):and exited 0. With fix: mxcli test finds test files in subfolders (closes #1363) #1368 it explains why on stderr, naming any misnamed files and any_folders it skipped. It still exits 0, because it's an inspection command. A pipeline that gates on tests should use a real run, or the JUnit output.Subfolders and positive controls.
mxcli test tests/now reads every subfolder, but skips folders whose names start with_or., the same convention the Go toolchain uses. Yourtests/unit/_control/therefore stays out of the default run on purpose now, not by accident. Each skipped_folder is named in the output, andmxcli test tests/unit/_control/runs it explicitly.fix: mxcli test finds test files in subfolders (closes mendixlabs#1363)
fix: mxcli test skips folders starting with _ and says why --list fou…
fix: mxcli test keeps going past a subfolder it cannot read (mendixla…