You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Initially I commented on #607 , but I then found out, that I can't reopen it, hence I decided to create a dedicated issue. I apologize if that's an unwanted noise.
Right now Command offers SetOutput method to set alternative io.Writer implementation for testing stdout/stderr interaction.
I think it would be great to be able to distinct standard output and error output here.
It is not uncommong for commands to report warnings to stderr. For example, take GNU's ls
$ ls -l /does/not/exist /tmp
ls: cannot access '/does/not/exist': No such file or directory
/tmp:
total 27776
...
If I were to reimplement this in go, I'd want to be sure, that ls: cannot access ... won't get to stdout, as it may be piped further. So I'd like to have test for that. With current cobra code it is not possible to test this behavior.
It looks like a very straightforward and simple change and we can even make it backward compatible with current API.
If there's interest and/or maintainers are open for this change, I'd be willing to work on it.
The text was updated successfully, but these errors were encountered:
koiuo
changed the title
Command.SetErrOutput for more finegrained testing
Command.SetErrOutput(io.Writer) for more finegrained testing
Oct 14, 2018
This is definitely necessary.
I would even go as far as adding a third method to redirec sdtin too.
Sometimes, CLIs need some input and we definitely need all these three to properly test things.
btw, this other open issue proposes the same. #658
Right now
Command
offersSetOutput
method to set alternativeio.Writer
implementation for testing stdout/stderr interaction.I think it would be great to be able to distinct standard output and error output here.
It is not uncommong for commands to report warnings to stderr. For example, take GNU's
ls
If I were to reimplement this in go, I'd want to be sure, that
ls: cannot access ...
won't get to stdout, as it may be piped further. So I'd like to have test for that. With current cobra code it is not possible to test this behavior.It looks like a very straightforward and simple change and we can even make it backward compatible with current API.
If there's interest and/or maintainers are open for this change, I'd be willing to work on it.
The text was updated successfully, but these errors were encountered: