Error when running tests specifying an absolute path

[jacobmendoza]

Hello!,

I'm using the version 0.13.0 with the following environment: Node.js v5.6.0, darwin 15.3.0.

When I execute ava in the same folder than its contents the operation gets completed without problem. However, if I try to do the same specifying an absolute path outside the folder that holds the file I get:

ava Repositories/x/y.js
1 exception

1. No tests found in Repositories/nodetests/test1.js, make sure to import "ava" at the top of your test file

Any idea?. Thanks!,

[vadimdemedes]

I just tried running AVA "remotely", outside project folder, and it worked fine. Are you sure you imported ava in test1.js? Also, repositories/x/y.js is still a relative path :)

[jacobmendoza]

@vdemedes, thanks for the reply!. My bad!, you're right, I was trying to say /Repositories/x/y.js. Anyway, after extending the tests, it's only happening outside the project folder, the detail of the absolute path was useless (sorry about that).

I've tried with a couple of repos that contain ava tests. These files contain import test from 'ava' in the header and run fine if the execution happens within the folder.

Maybe I have something wrong in my system.

[vadimdemedes]

I've tried absolute paths and it works that way too. Could you please try using AVA's master branch instead of the version on npm? Here's the commands you need to run:

$ npm i -g sindresorhus/ava

and inside project folder:

$ npm rm ava --save-dev
$ npm i sindresorhus/ava

[jacobmendoza]

First and foremost, thanks for all the support @vdemedes.

No joy :(. I've done:

npm i -g sindresorhus/ava
cd nodetests/
npm rm ava --save-dev
npm i sindresorhus/ava
ava test1.js (works)
cd ..
ava ./nodetests/test1.js (it does not work)

I put the entire sequence to show that I installed from sindresorhus/ava, went into the project folder, deleted ava, installed again and repeated the test, in and outside.

I don't know, seems to be something very strange. Btw, what I was trying to say before, is that I have just realised that the absolute path is a useless detail. At least for me, fails trying to run in a different folder (not the project).

[vadimdemedes]

No worries, @jacobmendoza, it's too bad I can't reproduce this. Perhaps someone else might help with this.

[jeffreywescott]

FWIW, I've run into this, too. I've done some debugging here, and this is what seems to be happening:

My package.json was using the require configuration to do some "test harness setup". In that file, I was importing 'ava'. Somehow, this confuses things. I'm not sure why, but I think it's probably related to forking and that variable doesn't stay "set to true". Bottom-line: importing 'ava' inside one of the ava require modules seems to break things.

As a workaround, ensure that none of your required modules are importing or requireing 'ava'.

[jacobmendoza]

In a separate conversation with @sindresorhus he confirmed that was able to reproduce and suggested this.

Just in case it helps to understand the root of the issue.

I'm very sorry that I forgot to copy this when opening the issue. I thought I did, but it seems that I completely missed it.

[sindresorhus]

Yes, I asked @jacobmendoza to open this.

I can easily reproduce by running AVA with an absolute path from a project that already depends on AVA:

~/dev/chalk master
❯ ava /Users/sindresorhus/dev/acosh/test.js

  ✖ No tests found in ../acosh/test.js, make sure to import "ava" at the top of your test file

[novemberborn]

Wouldn't dev/acosh/test.js require ava from dev/acosh/node_modules/ava? And the ava CLI (globally installed I assume) would be using dev/chalk/node_modules/ava.

[sindresorhus]

@novemberborn The global CLI just hands it directly off to the local AVA if available.

[novemberborn]

The global CLI just hands it directly off to the local AVA if available.

Yes, so if you're in dev/chalk the local AVA would be dev/chalk/node_modules/ava. The files pattern happens to be an absolute path though, and the test worker will require dev/acosh/node_modules/ava which might be a different AVA version. Similarly it might try to access the wrong .cache directory.

[sindresorhus]

Yes, we should ensure the test files require the same AVA as used to fork the test files.

[novemberborn]

That will be problematic across version boundaries. Maybe we should detect this scenario and refuse to run the tests?

[novemberborn]

@sindresorhus?

[sindresorhus]

Actually, when thinking about it, the current behavior makes sense. It should always use the AVA version in the current directory. Instead, we should introduce a cwd option in AVA. A warning like @novemberborn suggested would also be a good idea.

[jamestalmage]

Instead of adding an option, what if we just check the provided patterns to see if they reference stuff outside of cwd? If they all do, then just change cwd automatically. trying to run files in the current project and a different project with a single command should just be an error

[dawsbot]

Is there a workaround for the time being? Experiencing the same issues as @jacobmendoza.

sist output:

OS

Darwin - x64

node

npm -v: 3.9.5
node --version: v6.2.2

Time created: Tue Jul 05 2016 20:55:11 GMT-0700 (PDT)

[novemberborn]

To recap, when a globally installed AVA is launched it checks if there is a local AVA installation. If so it hands off to that installation, else the global AVA installation is used. Then for each test file AVA launches a child process. It starts a test worker inside the AVA module. This worker then requires the test file using an absolute path. It verifies the test file has required ava and defined tests. We're assuming the test file resolves ava to the same (cached) module as the worker. The problem here is that the test file resolved a different ava module.

There are three ways this problem can occur:

• There is no local AVA for the current working directory, but the test files (in a different directory) do find a different ava package
• There is a local AVA, but the test files still find a different ava package because they're in a different directory
• The test files are (nested) in the same directory as the local AVA, but there is a rogue node_modules which contains its own ava package

The best solution would be for the test worker to set environment variable (on process.env) containing the absolute path for the ava/index.js module. Then when a different ava/index.js is loaded it can hand off to the correct module. This should ensure test files load the same AVA instance as the test worker.

[sgnl]

I ran into this and it was because in the README.md it has the line "require": ['esm'], so I added that to my configuration file even though the readme didn't say anything about adding that line, I just assumed and did so.

https://github.com/avajs/ava/blame/6d12abfdff4478a1b6f4e87237764b89eb05f18d/readme.md#L308

removing this line now removes the "Tests not found in [file path here]" error and ava correctly sees my tests and reports are accurate.