Update binding for test explorer for unittest

[findNextStep]

This commits

• Add t t to open test explorer
• Add t u to run unittest under cursor
• Add t d to debug unittest under cursor
• Add t r to redebug last unittest

[findNextStep]

https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer

test explorer is unittest adaptor, with VSpaceCode key bind we can make it easy to run unittest

[stevenguh]

That's a great idea specially vscode released with the built-in testing API.

The hbenl.vscode-test-explorer currently might have a higher adoption, but as vsocde just release the official testing API in the last release. I expect that many language extensions or language specific language adaptors will use/convert to use the official built-in API.

Hence, I think it would be better for us to use the official testing command in the long run. Can you change the commands to use the built-in testing commands?

[findNextStep]

That's a great idea specially vscode released with the built-in testing API.

The hbenl.vscode-test-explorer currently might have a higher adoption, but as vsocde just release the official testing API in the last release. I expect that many language extensions or language specific language adaptors will use/convert to use the official built-in API.

Hence, I think it would be better for us to use the official testing command in the long run. Can you change the commands to use the built-in testing commands?

I see, let me have a try

[The-Compiler]

Some thoughts:

• This will kind of duplicate the test bindings which already exist in some modes (e.g. Python). Should we bind this under m t or so instead?
• I think a lot of useful bindings are missing, check my config for comparison
• In addition to those, debug-all and debug-file were added recently too: debug-all and debug-file commands? hbenl/vscode-test-explorer#211
• But indeed, if there is native VS Code test integration, I guess it makes sense to use those anyways.

[findNextStep]

Some thoughts:

• This will kind of duplicate the test bindings which already exist in some modes (e.g. Python). Should we bind this under m t or so instead?
• I think a lot of useful bindings are missing, check my config for comparison
• In addition to those, debug-all and debug-file were added recently too: debug-all and debug-file commands? hbenl/vscode-test-explorer#211
• But indeed, if there is native VS Code test integration, I guess it makes sense to use those anyways.

1. I think the test command is useful for all language, just like go define we not set into m.*
2. that`s great! I will check it out
3. let me see if native api support for that
4. i will chang to use vscode native command and i`m testing my setup

[stevenguh]

1. I think the testing commands in the major mode are so that it is similar to spacemacs. Currently, our SPC t doesn't really have many bindings it in, so I think it would be helpful to have testing outside of the major mode since it has support built-in. This would be a little bit like debug (SPC d) where individual major can provided more specific debug commands in the major mode. @marcoieni Any thoughts?
2. Most of them are available in the built-in testing api. See 3.
3. I usually look up shortcut by searching in keyboard shortcut editor.
   
4. Sounds good to me :)

[marcoieni]

1. I don't like a lot the idea to mix toggles and tests, so I think I prefer spc m t instead of spc t, but this is just my personal preference.

[stevenguh]

1. I don't like a lot the idea to mix toggles and tests, so I think I prefer spc m t instead of spc t, but this is just my personal preference.

I think there are two options:

1. Change the toggle to test. The reason being mostly because testing support is built-in and will be similar to debug (SPC d).
2. Add testing only to major mode. The reason being the testing support requires implementation from language extension and similarity to spacemacs. However, this means if a language doesn't have a major mode, the user won't be able to access testing menu.

Maybe we should start with adding them in the major modes, and standardized it somewhat like https://vspacecode.github.io/docs/conventions. So this will be mostly like how spacemacs work.

[findNextStep]

maybe we should use u as unittest, let t as toggle like how spacemacs work.

and I don`t think the native api should bind in major mode

[findNextStep]

by the way, where can I get the list of icon?

[findNextStep]

now i update the seting and bind key to u, show like this

[The-Compiler]

and I don`t think the native api should bind in major mode

We do have various other such bindings already though, e.g. the +Format menu in the major mode for almost all languages uses editor.action.format* commands, and so do almost all +Go to bindings. I don't really see the point in having test bindings available when I'm e.g. editing a Markdown or LaTeX document.

by the way, where can I get the list of icon?

https://code.visualstudio.com/api/references/icons-in-labels

[marcoieni]

Change the toggle to test. The reason being mostly because testing support is built-in and will be similar to debug (SPC d).

I don't like this, we should follow spacemacs conventions D:
By the way, I would not mix test and toggles because this is the toggle menu in spacemacs:

As you can see there is a lot we could add in the future.

We do have various other such bindings already though, e.g. the +Format menu in the major mode for almost all languages uses editor.action.format* commands, and so do almost all +Go to bindings. I don't really see the point in having test bindings available when I'm e.g. editing a Markdown or LaTeX document.

I think this makes sense, but everyone has its point. It's really hard to choose D:
Overall I prefer option 2 from Steven, because spc m t is what spaceamcs uses, so I think that maybe we should follow them..
Adding the same key bindings to something more opinionated like spc u is a non breaking change that we can do in the future, but everyone who comes from spacemacs expects to find those key bindings under spc m t.

[stevenguh]

I don't really see the point in having test bindings available when I'm e.g. editing a Markdown or LaTeX document

That's a good point especially testing api is not implemented by all language extensions. This feels similar to format commands in major mode where not all language implements all format commands. It's better to keep it in each language mode. We also have overrides for people who want to put testing top level.

I don't like this, we should follow spacemacs conventions D:

but everyone who comes from spacemacs expects to find those key bindings under spc m t.

Agree. It might be slow to add testing commands to each major mode; however, the testing commands in the major mode will guarantee to have testing support from the language extension.

[The-Compiler]

Agree. It might be slow to add testing commands to each major mode

I suppose VSpaceCode/vscode-which-key#42 would solve this kind of thing?

[stevenguh]

Agree. It might be slow to add testing commands to each major mode

I suppose VSpaceCode/vscode-which-key#42 would solve this kind of thing?

The slowness is from adding it into each specific major mode, and VSpaceCode/vscode-which-key#42 will help remove some of the redundancy of bindings in each major mode for example.

[stevenguh]

Closing this in favor of #248 tracking tasks with the solutions that we discussed.