Ava: When specifying glob pattern, test files 2 directories deep are ignored

[coopy]

Description

Thanks for working on AVA! I'm enjoying it very much so far. I've run into an edge case with globbing patterns, and have put up a repository reproducing the issue: https://github.com/coopy/ava-test-glob-repro

Overview

I have a source tree that looks like this (with test files in asrc/modules/deeper/ directory):

├── lib
│   ├── dep.js
│   └── dep.test.js
└── modules
    └── deeper
        ├── add.js
        └── add.test.js

When I run $ ava with defaults, all is good and tests are found and run.

Issue: When I run AVA with a file globbing pattern specified, only the tests in the shallower directory (lib/) are run .

$ ava src/**/*.test.js

Test Source

See full repro here:
https://github.com/coopy/ava-test-glob-repro

Error Message & Stack Trace

Running with file pattern (DOESN'T WORK AS EXPECTED)

$ ava src/**/*.test.js --verbose

  ✔ should return configuration

  1 test passed

Running with defaults (WORKS AS EXPECTED)

$ ava --verbose

  ✔ lib › dep › should return configuration
  ✔ modules › deeper › add › should add two numbers

  2 tests passed

Config

Copy the relevant section from package.json:

{
  "name": "ava-test-glob-repro",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "ava src/**/*.test.js --verbose"
  },
  "author": "",
  "license": "MIT",
  "description": "",
  "devDependencies": {
    "ava": "^0.24.0"
  },
  "dependencies": {
    "node-glob": "^1.2.0"
  }
}

Command-Line Arguments

Copy your npm build scripts or the ava command used:

ava src/**/*.test.js --verbose

Relevant Links

https://github.com/coopy/ava-test-glob-repro

Environment

Tell us which operating system you are using, as well as which versions of Node.js, npm, and AVA. Run the following to get it quickly:

$ node -e "var os=require('os');console.log('Node.js ' + process.version + '\n' + os.platform() + ' ' + os.release())"
darwin 17.3.0

$ ava --version
0.24.0

$ npm --version
5.6.0

[novemberborn]

@coopy thanks for the excellent issue report!

Most likely your shell is expanding the pattern, not AVA. Try quoting the patterns instead:

$ ava 'src/**/*.test.js' --verbose

This works for me. (Closing this issue but please let me know if this helps!)

[coopy]

Yep, quoting the pattern solves the issue. 🤦‍♂️ Thanks, @novemberborn! I'll add quoting globs in scripts to my list of best practices…

There is a curious difference apart from just the file matches, though. When I quote the glob (or just run ava --verbose without a pattern), it lists the full directory structure:

$ ava 'src/**/*.test.js' --verbose

  ✔ modules › deeper › add › should add two numbers
  ✔ lib › dep › should return configuration

  2 tests passed

When I run without the glob quoted, I just get the test description (for the test in the one matched path):

$ ava src/**/*.test.js --verbose

  ✔ should return configuration

  1 test passed

Either way, my issue is resolved.

[novemberborn]

@coopy if there's only a single test file the directory structure is not shown.

[danielgormly]

This was working on 1.x but is now broken for me on 2.0.0

[jonathansamines]

@danielgormly I just faced the same issue with ava 2.x.x, removing the quotes solves the issue though.

[dananichev]

@jonathansamines i believe you mentioned wrong user :)

[novemberborn]

Per the release notes: https://github.com/avajs/ava/releases/tag/v2.0.0

The CLI now only takes file paths, not glob patterns.

If you want to use glob patterns you should specify them in AVA's config, under the files key.

[cdaringe]

I understand that glob support is now in files, but why did it get _removed_ from the cli? did the args to the CLI not implicitly map into entries into the files configuration? thx :)

[novemberborn]

@cdaringe, in v1, you could pass directories and AVA would try and find test files inside of them. Combined with customizable file extensions it became quite hard to understand which files would be selected.

If Babel is enabled, AVA precompiles all test files based on the files configuration. It's simpler to reason that the CLI should receive files to execute without those necessarily impacting the pre-compilation.

Our bias for the CLI has been that configuration you always use should be in a configuration file, not a CLI argument. Thus, the CLI supports only a subset of the configuration.

Arguably I over-estimated how many people used globs on the CLI, even as a package.json run script, rather that configuring files. Though hopefully now that you can select which configuration to use through the CLI we've addressed most of those use cases.