Table driven tests and error/output testing

[Amit Saha]

Hi all, Consider the following test configuration:


func TestHandleCommand(t *testing.T) {

type expectedResult struct {
output string
err error
}
type testConfig struct {
args []string
result expectedResult
}

testConfigs := []testConfig{
testConfig{
args: []string{"-h"},
result: expectedResult{
err: nil,
output: `Expected output`,
},
},
}

Then, I do this:


for _, tc := range testConfigs {
byteBuf := new(bytes.Buffer)
w := bufio.NewWriter(byteBuf)

err := handleCommand(w, tc.args)
if tc.result.err == nil && err != nil {
t.Errorf("Expected nil error, got %v", err)
}

if tc.result.err != nil && err.Error() != tc.result.err.Error() {
t.Errorf("Expected error %v, got %v", tc.result.err, err)
}

if len(tc.result.output) != 0 {
w.Flush()
gotOutput := byteBuf.String()
if tc.result.output != gotOutput {
t.Errorf("Expected output to be: %v, Got: %v",
tc.result.output, gotOutput)
}
}
}
}

The above pattern works for me since the function may return an error
and/or it may have something it writes to the provided writer, w.

Is there a more concise way to write this?



Thanks,
Amit.

[Tamás Gulácsi]

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, you can save some allocations by creating the buffer once outside of the loop,

and Reset() it in each cycle before calling handleCommand.

[Amit Saha]

On 20 Oct 2020, at 4:13 pm, Tamás Gulácsi <tgula...@gmail.com> 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, you can save some allocations by creating the buffer once outside of the loop,

and Reset() it in each cycle before calling handleCommand.

Thank you, appreciate the suggestions.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2759fea4-a3d6-42ee-b3e4-2c0ac208f2b9n%40googlegroups.com.

[seank...@gmail.com]

you should be able to unconditionally compare the output without doing the length check

[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.go.dev/github.com/rogpeppe/go-internal/testscript for more details.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CANODV3%3DsOA4FKakaQ0mrcC%3D-BnVNq8SdnvDHgXShmrRt-_upHw%40mail.gmail.com.

[Amit Saha]

On 21 Oct 2020, at 8:31 am, roger peppe <rogp...@gmail.com> 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 expect-stdout

    -- expect-stdout --

    Expected output

See https://pkg.go.dev/github.com/rogpeppe/go-internal/testscript for more details.

This looks interesting, thank you. I will have a look.