Test Explorer

[endragor]

Would like to see a view with time statistics per file/test. This will help to identify tests that are taking longer than I would expect.

[ArtemGovorov]

@endragor I'll steal the issue to extend the scope a bit if you don't mind.

It'd be nice to have a filterable and searchable tree of all tests, where apart from the execution time, other test data would be listed.

[usefulthink]

👍

[brettjacobson]

I was just curious if there is progress on the Test Explorer?

[ArtemGovorov]

@brettjacobson There's been some progress, but not very substantial yet. We do get a lot of requests for the feature though from IntelliJ users and Atom users as well.

I have been thinking of perhaps providing a couple of reports (Test Explorer and Coverage) that could be opened from an IDE but in a browser. That would be the easiest and the fastest way for us to implement and release it, as opposed to doing 3 IDE specific implementations.

Even though HTML report will not be as 'integrated' as the rest of wallaby features, these reports is not something that is used as frequently as other features, so perhaps a little context switching (from IDE to browser) is not a big deal here.

Your thoughts?

[endragor]

That works for me.

[fvanwijk]

I think it is a good start, since we are used to get a HTML coverage report with Karma/Istanbul as well (there is no good IDE integration yet). However, I really like to eventually have IDE integration for coverage etc. because lack of context switches makes Wallaby so powerful.

[brettjacobson]

I think an HTML coverage report would be useful, but it would only be useful every once in awhile. A Test explorer window would be useful all the time I think, since it would serve many purposes.

[ArtemGovorov]

Thanks for your feedback guys.

@brettjacobson

A Test explorer window would be useful all the time I think, since it would serve many purposes.

How often would you use the window? I understand that sometimes one may need to use it for a few minutes or even more, but working with the window is already a context switching from writing code right? So my question is - would you need to keep the tests tree open all the time while you write code?

[brettjacobson]

With NCrunch I keep the ncrunch Tests window open on a secondary monitor. Perhaps NCrunchs' window is valuable to us because our C# unit test suite is much larger (and slower) than our JS test suite, so its advantageous to get progress reports on test runs (even when optimized to run only affected tests).

I definitely use the ncrunch test window as a test code navigation aid. I think I would like to use a wallaby test window for the same purpose

Perhaps you can summarize what possible requirements for a Test Explorer that you've gathered/planned?

[ArtemGovorov]

With NCrunch I keep the ncrunch Tests window open on a secondary monitor.

So you wouldn't mind if in wallaby case it was a browser window if it had the features you need?

Here is a summary of features for the Test Explorer that I had in mind (note that the Coverage Report is a separate view with its own set of requirements/features, though some of its data may end up in the Test Explorer):

Minimal set of features for v1:

• Displaying all tests in a tree (name + execution time).
• Displaying details of a selected test (execution time, errors if any, console.log output for test).
• Allowing to jump to the selected test code, its error stack lines and console.log positions.
• Allowing to run the selected test/suite or all project tests.

Advanced features to add later:

• Allowing to group/order/filter tests by file/test name, execution time, failed/passed state, etc.
• Displaying detailed test execution progress and what tests are currently running.

Your thoughts?