-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adds support to execute ginkgo tests on terminal #1
base: master
Are you sure you want to change the base?
Adds support to execute ginkgo tests on terminal #1
Conversation
- creates a specific class to execute the ginkgo tests that is called by the treeDataProvider. - Adds ginkgoPath to the treeDataProvider and updates it when the config is changed. - Updates the GinkgoNode interface on outliner file to make the parent attribute as optional. It make sense once the root node does not have a parent node.
@dlipovetsky please, let me know what do you think?! |
Hey @dlipovetsky , just to mark you again, maybe you didn't see the notification. =) |
Thanks so much @ricardogpsf. Makes me feel great to hear that.
Making it easier to run tests would be a great feature, and I'm excited to try out your PR! Apologies for the long wait; I've been very busy the last weeks. |
I'm enjoying the spec execution. Nice work! Also, thanks for identifying the bug with the First, the Second, the spec execution. I tried it out, and it works great! However, I think it would be hard to discover the feature. The convention that I have seen for running tests are links that appear in-line with the document. For example, the "run test | debug test" links that vscode-go places above the go I think these links are implemented as a CodeLensProvider. I also realized that I was already using a double-click to "go to" the spec in the editor. I guess now a double-click both "goes to" the test, and runs it. So this PR breaks the simpler functionality of "go to" the spec in the editor. I'd like to avoid that, if practical. Do you think exposing the "run spec" feature through a context menu be practical in this PR? Finally, I found some surprising behavior. When I ran a spec, I noticed that an unrelated spec also ran. It turns out that there the specs had the same text, all the way to the root spec. So when the Here's a recording: Reading https://onsi.github.io/ginkgo/#focused-specs, I don't see any way to do it. This is a limitation of |
Hey man, thanks for your answer and feedback.
Nice!
Yes, it seems weird, but when you apply a JSON.parse() you are working a weak structure (without type defined) and when you expect a GinkgoNode you are working with nested nodes that always have a parent. So in your code, you didn't need to access a parent node from a node without a parent. In my case, I have this situation in the test. I'm not typescript expert, too. =(
Yeah, I agree with you. The idea was just to prove a concept. I didn't work with VSCode plugin before it, and I didn't know if you would see (or like) my PR. hahaha}
Ok, I got it. Yes, exposing a context menu or lens is a better way to do it.
Yep, you're right. The
I don't see a big problem keeping that strategy. To me, the good thing is to see the command on terminal to execute it again manually without being needed to write it from scratch. |
@dlipovetsky anyway, I've discussed with my coworkers about your plugin and strategies to increase features and etc.... Maybe it's a good idea (and a good way) to merge both (your plugin and his one), I mentioned it to him. What do you think? |
It looks really good. (Nice work @joselitofilho! And I appreciate the link back to this project from the README.)
Sure! For example, we could form a github organization for a common project. But it's also ok to keep them separate. That's the beauty of open source 😄 . |
@dlipovetsky your project was very inspiring, thanks for that. |
Firstly, thank you for this plugin, it helped me and I loved it. =)
I was searching for something like that and that works, and this one works very well.
The idea of this PR is after a double click on the TreeView, execute the test of the Spec clicked on the active terminal.
If no one terminal is active, the test is no executed and a message is sent to the outputChannel.
If an
It
element is selected/clicked only its test is executed, if aWhen
orContext
orDescribe
element is selected, all nested are executed.I had some problems creating unit tests for the code that invokes
vscode
module, so I avoid calling it inside the method tested, and I tested only one method. =(If you liked it and think it like interesting to have it in the master branch, I'll create a gif to put in the README with an test execution example.