hide the first two levels in Karma test tree

[segrey]

Now Karma test tree looks like this:

Test Results
|_ karma.conf.js
    |_ Chrome 28.0.1500 (Linux)
          |_<suite name>
                  |_ <spec name>

Root node {{Test Results}} is useless and can be removed.
If there is only one browser captured, the test tree could look like this:

karma.conf.js (Chrome 28.0.1500 (Linux)
|_<suite name>
    |_ <spec name>

If there are more than one browsers captured, the test tree could look like this:

karma.conf.js
|_ Chrome 28.0.1500 (Linux
     |_<suite name>
          |_ <spec name>
|_ Firefox
     |_<suite name>
          |_ <spec name>

[vojtajina]

I would hide even the karma.conf.js (unless there is more configurations).

[segrey]

It isn't obvious for me, because even if there is only one run configuration, there could be several *.conf.js Karma config files. Moreover, it could be convenient to navigate to Karma config to edit/view it.

Okay, let's pretend that karma.conf.js node was removed. Would the browser name be displayed in that case?
Or just:

<suite name>
|_ <spec name>

?

[vojtajina]

If I was using multiple karma.conf.js files (which is possible), I would
have a separate configuration for them and therefore I think there's always
gonna be just a single item of "karma.conf.js". I can see which
configuration it is based on the title. So I would definitely remove the
"karma.conf.js" item.

With browsers, I'm not sure. Definitely good to keep browsers if there's
multiple captured browsers. I would keep the browser name even if there's
only one browser captured.

Also, shouldn't the tests be nested - a tree structured ? (it's flat now,
see my screenshot)

On Tue, Jul 16, 2013 at 12:12 PM, Sergey Simonchik <[email protected]

wrote:

It isn't obvious for me, because even if there is only one run
configuration, there could be several *.conf.js Karma config files.
Moreover, it could be convenient to navigate to Karma config to edit/view
it.

Okay, let's pretend that karma.conf.js node was removed. Would the
browser name be displayed in that case?
Or just:

|_

?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-21065934
.

[vojtajina]

Here's the screenshot - flat restuls, I think it should be a tree structure of suites and specs.

[segrey]

About flat results: it seems to be a bug.

Could you please file a new issue and attach there an output of the following command:

• Select "Test Results" node
• Copy the first line from the console located on the right side. It's a command line that WebStorm launches to get output from to build the test tree.
• Execute this command line and save its output. This output can help us to understand the cause of flat results.

Also if possible please attach the project, I'll try to reproduce the issue on my machine.

[segrey]

About removing "karma.conf.js": your arguments make sense.
There are two things that stop me:

• "karma.conf.js" node navigates you to Karma config file. That is convenient, if you need to fix the config file and rerun the tests
• According to our IDE implementation, the test result tree should have a root node.
  In your case we would have the following test trees (correct me if I'm wrong):
  If we have one browser captured, then Chrome 28.0.1500 could be the root node.
  What would be the root node if there are multiple browsers captured? It seems that "karma.conf.js" is an ideal candidate for that.

Such test trees are quite similar to the suggested test trees from the issue description. The only difference is that we'll have karma.conf.js (Chrome 28.0.1500) as a root node if we have only one browser captured.

Maybe I'm missing something. Feel free to correct me.

[vojtajina]

Clicking karma.conf.js might be convienient to edit the file, but I personally use CMD+O (the clever open file ala TextMate) for everything, so I wouldn't use it anyway.

I think most of the cases, people only use one browser, so I would make "Chrome 28..." the root. If there are multiple browsers, wrap it into whatever you like. How difficult would it be to extend your "tree" component to allow multiple roots or at least hidding the single root ?