-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Document a best practice for testing a cobra app #770
Comments
Could anyone share how they write tests for sub-commands? I am also stuck i find it really hard to write any kind of test for a more complex sub-command. Thanks |
I've found an example here https://chromium.googlesource.com/external/github.com/spf13/cobra/+/refs/heads/master/command_test.go |
If you are coming here from a Google or DuckDuckGo search, in our project we wrapped the var and init sections of the commands in functions so that they can be called by unit tests and re-initialize all variables. |
Hi! @lpabon your links are broken. Could you reupload? 🙏 |
@lpabon Maybe the repo |
it would be nice to have guidance or even some kind of default skeleton which includes a test director and hooks that up in an opinionated way. instead of having to search around for how everyone else is doing it their specific quirky way |
This issue is being marked as stale due to a long period of inactivity |
Thanks for the reference test implementation, it was helpful. However, i'm struggling with resetting flags to default values. I've ended up with this monstrosity:
Is there a better way to reset flags? |
@myaut Cobra does have a ResetFlags() method. Does that help you at all? |
I went with the strategy described at https://stackoverflow.com/questions/59709345/how-to-implement-unit-tests-for-cli-commands-in-go/59714127#59714127
|
It's been 2 years but still +1 for the issue. Any best-practice-article or samples for testing As a Golang beginner, even a simple "Hello, world!" command which has a "hello" sub-command with best practices and tests that cover 100% of coverage would help. I never get covered the last few percentages ... I know that keeping 100% coverage is a fantasy. But at least we can start at 100%, don't we? [Edit] 2021/01/14 |
Hey folks, I've struggled with testing sub commands myself and somehow managed to finally achieve it. And I wrote an article about it. https://g14a.github.io/posts/Testing-Cobra-Subcommands @sethcenterbar @shilangyu |
Very cool, I'll check it out soon! Thanks for writing an article :) |
There are some other issues, and a general concensus, that we need to rework the default app and I think showcasing how to do basic testing as well in that would make sense. Since there are other similar tickets and this issue has a linked article discussing a solution, I'm going to close. Feel free to reopen if you think this ticket specifically should stay open or you think the solution should be different. |
I still wonder if there exists a simple case for testing the subcommand, I am a little bit struggling with this. Welcome more people sharing the test cases. |
unable to access the link |
Hey there, I'm quite new to go and cobra, but I'm leveraging the framework to build some tools for work and loving it.
I've been trying to set up testing for my project, but I'm wondering how other people using cobra are implementing testing for sub-commands. The typical go example led me to believe that in the cmds folder, i would make a command x.go and then create a test x_test.go. Because of the way that all of the commands are passed to the root command, I don't believe this is possible.
To other users, how would you suggest doing testing on your sub-commands? If this isn't just a noob misunderstanding, maybe it would be good to add a best practice for testing into the main readme?
The text was updated successfully, but these errors were encountered: