Support running all tests in a project about atom-ava HOT 10 OPEN

I think separate keyboard shortcut, but the "run all" should be the "default one" (i.e. require less modifier keys be pressed).

I don't recall what the exact keyboard shortcut was for #8. ctrl-alt-a? Assuming that:

• ctrl-alt-a: run all files.
• ctrl-alt-shift-a: run a single file.

from atom-ava.

Hey @sindresorhus:

The current implementation should require small modifications to run all the tests of the project. As you said, it should be as easy as spawning AVA with no arguments.

IMO, To make it really valuable, the package should clearly state what tests belong to each file in the project. Something as:

The problem that I see (and please, let me know if I'm missing something) is that there is no way to deduct the file that contains the file with the current TAP reporter output. This 'problem' could also be extended to what would be the best way to write extra information beyond the basics of TAP (times of execution, part of the lexical analysis or parsing as the number of the line of the assert, etc).

The reporter receives now, among other fields the duration and the file. For this case, if the file could be written to the output that would make possible put the tests grouped as in the image. Does that idea break somehow what you would expect from a TAP output?. Would a diagnostic line (according to the TAP specification) be the correct way?.

Depending on your reply (I don't know if this makes sense) I was planning to comment avajs/ava#648.

@jamestalmage, I agree, I think that makes sense.

from atom-ava.

With multiple files, the test title should reflect the file it's run in:

$ ./cli.js --tap test/fixture/es2015.js test/fixture/async-await.js 

TAP version 13
# es2015 › [anonymous]
ok 1 - es2015 › [anonymous]
# async-await › async function
ok 2 - async-await › async function
# async-await › arrow async function
ok 3 - async-await › arrow async function

1..3
# tests 3
# pass 3
# fail 0

It should just be a matter of splitting on › (which is different from >, BTW).

from atom-ava.

@jamestalmage, that's great!. Sorry, but I have completely missed this behaviour.

I think we can use it to implement the feature. The only possible problem that I see is that, given a list of files in an Atom project, I should be able to get only the JS files that could contain tests. Would that mean that I need to replicate to some extent this logic?:

https://github.com/sindresorhus/ava/blob/master/cli.js#L169

Is that the best option?. Is it possible to make the TAP reporter aware of the fact that we are running more than one file and print the file in those cases without providing the list of files to the CLI?. I'll take a look at the code.

from atom-ava.

If you are using the AVA CLI, then you don't need to do anything. If there is a single file, the file name is prepended, otherwise it is not.

• run-status.js
• api.js

from atom-ava.

given a list of files in an Atom project, I should be able to get only the JS files that could contain tests

Just running ava in the main folder of the project will find all the tests. You shouldn't have to figure out which tests to run.

from atom-ava.

What James said, and if there's any missing info, we can put it in the TAP YAML block, which can contain any custom info.

from atom-ava.

Sorry, I did not have my best moment trying to explain this the other day.

The package launches now the following command:
ava somefile.js --tap

My intention was add a different case for running all the tests as:
ava --tap

As James said, running AVA in the main folder already discovers the tests and you don't need to worry about that. If the convention that AVA uses now ('test.js', 'test-*.js', 'test') changes in the future, we don't have any extra maintenance point. What I missed completely was that the TAP reporter is already writing some information about the file when multiple files are included!.

When running AVA with files named as test-*.js (test-111.js, test-1.js, sometest-after.js) the word test gets removed (111, 1, someafter). As far as I've seen, the reporter is already receiving the title in that format. What is the intent? Is trying to improve readability skipping the 'test' part?.

What I wonder is, how do we want the Atom package to behave?. I thought that we were going to display the filenames, but maybe you want to see this friendly version, assuming that I got the motivation right.

Thank you! :)

from atom-ava.

Start building your integration / UI with the "friendly" one. We will add an option or extra yaml property to get you the full file eventually

from atom-ava.

Thank you James!. Will do.

from atom-ava.