Re: [go-nuts] Table driven tests and error/output testing

2020-10-22 Thread Amit Saha
> On 21 Oct 2020, at 8:31 am, roger peppe wrote: > > It looks like you're testing a top level command. You might want to consider > using the testscript package, which provides a very concise way of end-to-end > testing this kind of thing. > > e.g. > > mycommand -h > cmp stdout expe

Re: [go-nuts] Table driven tests and error/output testing

2020-10-20 Thread roger peppe
It looks like you're testing a top level command. You might want to consider using the testscript package, which provides a very concise way of end-to-end testing this kind of thing. e.g. mycommand -h cmp stdout expect-stdout -- expect-stdout -- Expected output See https://pkg.g

Re: [go-nuts] Table driven tests and error/output testing

2020-10-20 Thread seank...@gmail.com
you should be able to unconditionally compare the output without doing the length check On Tuesday, October 20, 2020 at 8:51:56 AM UTC+2 amits...@gmail.com wrote: > > On 20 Oct 2020, at 4:13 pm, Tamás Gulácsi wrote: > > Use bytes.Buffer or strings.Builder directly - no need for the > bufio.Wri

Re: [go-nuts] Table driven tests and error/output testing

2020-10-19 Thread Amit Saha
> On 20 Oct 2020, at 4:13 pm, Tamás Gulácsi wrote: > > Use bytes.Buffer or strings.Builder directly - no need for the bufio.Writer. > bufio.Writer only speeds up writing by calling the underlying Writer less, > with bigger slices. > Here you Write into a memory, just as bufio.Writer. > > Also

[go-nuts] Table driven tests and error/output testing

2020-10-19 Thread Amit Saha
Hi all, Consider the following test configuration: func TestHandleCommand(t *testing.T) { type expectedResult struct { output string errerror } type testConfig struct { args []string result expectedResult } testConfigs := []testConfig{