Atom plugin

[limafelipe]

Have any plugin to use in Atom?

[sindresorhus]

For what purpose? What would it do?

[limafelipe]

Something like this https://atom.io/packages/atom-mocha
I belive that can help to run tests directly in Atom to optimize time to alternate screens.

[limafelipe]

In the WebStorm the test suite is pretty nice! See this print:

[vadimdemedes]

That's actually a nice idea! Although I think it should be postponed until we are more close to 1.0 release.

[markthethomas]

I agree w/ @vdemedes; one of the most frustrating things I've encountered is when a plugin is out of sync with the api it's supposed to be helping me with. I usually just have to end up disabling it till it gets updated.

[limafelipe]

Perfect, dude!

[sindresorhus]

I don't think I would want to have a big tree view, but seeing the test result in the status bar and clicking it taking me to the failing test could be mildly useful. I think an editor plugin will be much more useful when we add support for incremental testing #115, as we could then show the test result almost instantly on save and even inline in the test file. We should wait until after 1.0.0 regardless.

[limafelipe]

Really, the tree view is more beautiful than useful, the only cool thing is when clicking in the icon with the test title it goes to file and line of the test. So, when a test has error is very easy go to him.

[varemenos]

I understand this isn't an immediate goal for the project but I would like to recommend an atom testing package for inspiration: https://github.com/jacobmendoza/rspec-tree-runner

Imho it's UI is spot on for testing

[sindresorhus]

@varemenos That looks amazing! Much more in line with what I would like to see.

@jacobmendoza Would you be interested in modularizing it out into more reusable components? I imagine a lot of test runners could benefit from your work on this. This really shows the power of the editor just being JS and CSS. Would be cool to have something like Atom Linter, but for test runners.

[jacobmendoza]

Hi!

@varemenos I really appreciate that you mentioned the plugin. Really, thank you :).

@sindresorhus, I'd be very interested in participating!. The first thought that comes to my mind (and I may very well be wrong) is that maybe the idea of modularizing the plugin could be too ambitious. I was wondering, if doing something specific for AVA could make more sense and be more realistic (I guess that, to some extent, a complete specific solution could lead to interesting things).

Again, I could be wrong, it's only the first thing that came to my mind. Very interesting the conversation about the UI anyway.

So, do you see it as something that could potentially be interesting?.

Thanks!

[sindresorhus]

I haven't really dug into the code yet. Was just my first thought to make it easier to reuse things in a potential AVA plugin. I just got an idea though. If you would add support for TAP potentially any test runner could be made compatible with it. AVA plans to add support for TAP (#27) and most existing test runners support it. What do you think?

[jamestalmage]

TAP is a good idea, but a specific integration could offer some really cool stuff too.

A few ideas:

1. the power-assert instrumentation already captures the line numbers and values of every assertion. So we we could put check boxes next to every assertion in the code editor as it runs. When you mouse over (even a passed assertion), we could still output the espower graph in a popup. That could be handy if you follow the practice of writing failing test first and are surprised by a passing test. Also if you have some complicated assertion that's passing for reasons you don't understand:

   t.ok(/complicatedRegex/.test(stringThatPassesForUnforseenReason));
                           |    |
                           |    "string value"
                           true

2. Also, with AVA's concurrent test runs, logging statements from multiple processes are getting piped to stdout concurrently. That can cause confusion as to what output belongs to the test that is failing. Inside an IDE we could track those separately and only show stdout from the relevant test file.

3. It would be pretty cool to somehow automatically / seamlessly turn just changed tests into test.only behind the scenes. (Though we could probably implement that kind of magic outside of AVA/Atom entirely).

[jprichardson]

If you add TAP support, I can get AVA running really easily in my plugin: https://github.com/jprichardson/trinity. Sorry, no screenshots yet. Works similarly to the others. But, I use it all day, every day and it works great. Supports Mocha and Tape out of the box as it just parses TAP output.

[jacobmendoza]

Actually, it seems that supporting TAP would make a lot of sense. Several plugins could benefit from that (As @jprichardson, f.e). Don't have the required knowledge about AVA to add anything to @jamestalmage comments.

Regarding rspec-tree-runner code, just a quick update. The entire plugin is some sort of learning experiment and I don't have much experience in any of the technologies involved, so probably it'll be easy to find a lot of bad decisions.

There is a ruby script that gets the AST from the RSpec file, the tree is parsed in Atom and rendered. A different module runs the tests and parses the output from the RSpec test runner. The package also supports toggling between the code and the spec file, following to the typical ruby/rails project conventions.

[sindresorhus]

AVA now has TAP output with the --tap flag.

Continued in avajs/atom-ava#3.

Also see avajs/atom-ava#2.