go test: standard input
1,675 views
Skip to first unread message
Archos
Feb 9, 2012, 1:04:19 AM2/9/12
to golang-nuts
Since weekly.2012-02-07 release, the new "go test" runs tests with
standard input connected
to "/dev/null". So if you have a program that uses the file descriptor
for "/dev/stdin" (which is 0) then it is going to fail at test it.
The solution is to get the terminal name where you program is running
to use its file descriptor. It's got using the command "tty".
But luckyly, there is a easier way since "/dev/tty" is something like
a link to the actually terminal device name. For the shell process
you're in, "/dev/tty" is the terminal you are now using.
standard input connected
to "/dev/null". So if you have a program that uses the file descriptor
for "/dev/stdin" (which is 0) then it is going to fail at test it.
The solution is to get the terminal name where you program is running
to use its file descriptor. It's got using the command "tty".
But luckyly, there is a easier way since "/dev/tty" is something like
a link to the actually terminal device name. For the shell process
you're in, "/dev/tty" is the terminal you are now using.
Archos
Feb 9, 2012, 9:41:06 AM2/9/12
to golang-nuts
It's possible that there are not many programs using the standard
input but this is a source of problems for the developers if it is not
well solved.
I think that when is run "go test" should be added an environ
variable. So the programs that use the standard input will know when
to use a different file to os.Stdin.
By now, you can set a boolen in the program/package which would be set
up it in the test files.
input but this is a source of problems for the developers if it is not
well solved.
I think that when is run "go test" should be added an environ
variable. So the programs that use the standard input will know when
to use a different file to os.Stdin.
By now, you can set a boolen in the program/package which would be set
up it in the test files.
Archos
Feb 9, 2012, 10:09:17 AM2/9/12
to golang-nuts
On Feb 9, 2:41 pm, Archos <raul....@sent.com> wrote:
> It's possible that there are not many programs using the standard
> input but this is a source of problems for the developers if it is not
> well solved.
>
> I think that when is run "go test" should be added an environ
> variable. So the programs that use the standard input will know when
> to use a different file to os.Stdin.
> By now, you can set a boolen in the program/package which would be set
> up it in the test files.
It's better to use a mock to pass data, and/or to use "/dev/tty" in
the test file if were necessary.
Jan Mercl
Feb 9, 2012, 11:08:59 AM2/9/12
to golan...@googlegroups.com
On Thursday, February 9, 2012 3:41:06 PM UTC+1, Archos wrote:
It's possible that there are not many programs using the standard
input but this is a source of problems for the developers if it is not
well solved.
I think that when is run "go test" should be added an environ
variable. So the programs that use the standard input will know when
to use a different file to os.Stdin.
A running rogram can check its own binary name. If it is e.g. foo.test, then it was built and invoked by 'go test' with stdin connected to /dev/null.
Archos
Feb 9, 2012, 1:34:24 PM2/9/12
to golang-nuts
Also, you could also pass "os.Stderr" to a function with an argument
*os.File, when is run in the test files. Or "syscall.Stderr" if the
argument is a file descriptor.
*os.File, when is run in the test files. Or "syscall.Stderr" if the
argument is a file descriptor.
Archos
Feb 9, 2012, 1:46:21 PM2/9/12
to golang-nuts
Just for archiving. It is not appropriate to use "/dev/tty" because it
is specifix to Unix:
http://code.google.com/p/go/issues/detail?id=2937
is specifix to Unix:
http://code.google.com/p/go/issues/detail?id=2937
Kyle Lemons
Feb 9, 2012, 2:30:43 PM2/9/12
to golang-nuts
Arguably, your tests should not be reading (or caring about) standard input. That makes them brittle and possibly flaky (especially if they're interactive). If something under test does care, then stub out the call or inject a dependency which you can swap out during testing.
Archos
Feb 9, 2012, 4:50:11 PM2/9/12
to golang-nuts
That depends of the program to testing. In my case is for programs
that change the terminal to raw mode for then to set the prompt and
testing its input. Here you need an interactive test to checking the
movements of the cursor.
that change the terminal to raw mode for then to set the prompt and
testing its input. Here you need an interactive test to checking the
movements of the cursor.
Kyle Lemons
Feb 9, 2012, 5:07:09 PM2/9/12
to Archos, golang-nuts
That depends of the program to testing. In my case is for programs
that change the terminal to raw mode for then to set the prompt and
testing its input. Here you need an interactive test to checking the
movements of the cursor.
Interestingly, I have a package that does exactly that, and it still manages to have non-interactive unit tests.
Reply all
Reply to author
Forward
0 new messages