DockerCLI/cli/command/network/remove_test.go

121 lines
3.1 KiB
Go
Raw Normal View History

package network
import (
"context"
"io"
"testing"
"github.com/docker/cli/internal/test"
"github.com/docker/docker/api/types/network"
"github.com/docker/docker/errdefs"
"github.com/pkg/errors"
"gotest.tools/v3/assert"
is "gotest.tools/v3/assert/cmp"
)
func TestNetworkRemoveForce(t *testing.T) {
tests := []struct {
doc string
args []string
expectedErr string
}{
{
doc: "existing network",
args: []string{"existing-network"},
},
{
doc: "existing network (forced)",
args: []string{"--force", "existing-network"},
},
{
doc: "non-existing network",
args: []string{"no-such-network"},
expectedErr: "no such network: no-such-network",
},
{
doc: "non-existing network (forced)",
args: []string{"--force", "no-such-network"},
},
{
doc: "in-use network",
args: []string{"in-use-network"},
expectedErr: "network is in use",
},
{
doc: "in-use network (forced)",
args: []string{"--force", "in-use-network"},
expectedErr: "network is in use",
},
{
doc: "multiple networks",
args: []string{"existing-network", "no-such-network"},
expectedErr: "no such network: no-such-network",
},
{
doc: "multiple networks (forced)",
args: []string{"--force", "existing-network", "no-such-network"},
},
{
doc: "multiple networks 2 (forced)",
args: []string{"--force", "existing-network", "no-such-network", "in-use-network"},
expectedErr: "network is in use",
},
}
for _, tc := range tests {
tc := tc
t.Run(tc.doc, func(t *testing.T) {
fakeCli := test.NewFakeCli(&fakeClient{
networkRemoveFunc: func(ctx context.Context, networkID string) error {
switch networkID {
case "no-such-network":
return errdefs.NotFound(errors.New("no such network: no-such-network"))
case "in-use-network":
return errdefs.Forbidden(errors.New("network is in use"))
case "existing-network":
return nil
default:
return nil
}
},
})
cmd := newRemoveCommand(fakeCli)
cmd.SetOut(io.Discard)
cmd.SetErr(fakeCli.ErrBuffer())
cmd.SetArgs(tc.args)
err := cmd.Execute()
if tc.expectedErr == "" {
assert.NilError(t, err)
} else {
assert.Check(t, is.Contains(fakeCli.ErrBuffer().String(), tc.expectedErr))
cli: make cli.StatusError slightly prettier This error didn't do a great job at formatting. If a StatusError was produced without a Status message, it would print a very non-informative error, with information missing. Let's update the output: - If a status-message is provided; print just that (after all the status code is something that can be found from the shell, e.g. through `echo $?` in Bash). - If no status-message is provided: print a message more similar to Go's `exec.ExecError`, which uses `os.rocessState.String()` (see [1]). Before this patch, an error without custom status would print: Status: , Code: 2 After this patch: exit status 2 In situations where a custom error-message is provided, the error-message is print as-is, whereas before this patch, the message got combined with the `Status:` and `Code:`, which resulted in some odd output. Before this patch: docker volume --no-such-flag Status: unknown flag: --no-such-flag See 'docker volume --help'. Usage: docker volume COMMAND Manage volumes Commands: create Create a volume inspect Display detailed information on one or more volumes ls List volumes prune Remove unused local volumes rm Remove one or more volumes update Update a volume (cluster volumes only) Run 'docker volume COMMAND --help' for more information on a command. , Code: 125 With this patch, the error is shown as-is; docker volume --no-such-flag unknown flag: --no-such-flag See 'docker volume --help'. Usage: docker volume COMMAND Manage volumes Commands: create Create a volume inspect Display detailed information on one or more volumes ls List volumes prune Remove unused local volumes rm Remove one or more volumes update Update a volume (cluster volumes only) Run 'docker volume COMMAND --help' for more information on a command. While the exit-code is no longer printed, it's still properly handled; echo $? 125 [1]: https://github.com/golang/go/blob/82c14346d89ec0eeca114f9ca0e88516b2cda454/src/os/exec_posix.go#L107-L135 Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2024-07-04 13:02:33 -04:00
assert.ErrorContains(t, err, "exit status 1")
}
})
}
}
func TestNetworkRemovePromptTermination(t *testing.T) {
ctx, cancel := context.WithCancel(context.Background())
t.Cleanup(cancel)
cli := test.NewFakeCli(&fakeClient{
networkRemoveFunc: func(ctx context.Context, networkID string) error {
return errors.New("fakeClient networkRemoveFunc should not be called")
},
networkInspectFunc: func(ctx context.Context, networkID string, options network.InspectOptions) (network.Inspect, []byte, error) {
return network.Inspect{
ID: "existing-network",
Name: "existing-network",
Ingress: true,
}, nil, nil
},
})
cmd := newRemoveCommand(cli)
cmd.SetArgs([]string{"existing-network"})
test spring-cleaning This makes a quick pass through our tests; Discard output/err ---------------------------------------------- Many tests were testing for error-conditions, but didn't discard output. This produced a lot of noise when running the tests, and made it hard to discover if there were actual failures, or if the output was expected. For example: === RUN TestConfigCreateErrors Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: "create" requires exactly 2 arguments. See 'create --help'. Usage: create [OPTIONS] CONFIG file|- [flags] Create a config from a file or STDIN Error: error creating config --- PASS: TestConfigCreateErrors (0.00s) And after discarding output: === RUN TestConfigCreateErrors --- PASS: TestConfigCreateErrors (0.00s) Use sub-tests where possible ---------------------------------------------- Some tests were already set-up to use test-tables, and even had a usable name (or in some cases "error" to check for). Change them to actual sub- tests. Same test as above, but now with sub-tests and output discarded: === RUN TestConfigCreateErrors === RUN TestConfigCreateErrors/requires_exactly_2_arguments === RUN TestConfigCreateErrors/requires_exactly_2_arguments#01 === RUN TestConfigCreateErrors/error_creating_config --- PASS: TestConfigCreateErrors (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments (0.00s) --- PASS: TestConfigCreateErrors/requires_exactly_2_arguments#01 (0.00s) --- PASS: TestConfigCreateErrors/error_creating_config (0.00s) PASS It's not perfect in all cases (in the above, there's duplicate "expected" errors, but Go conveniently adds "#01" for the duplicate). There's probably also various tests I missed that could still use the same changes applied; we can improve these in follow-ups. Set cmd.Args to prevent test-failures ---------------------------------------------- When running tests from my IDE, it compiles the tests before running, then executes the compiled binary to run the tests. Cobra doesn't like that, because in that situation `os.Args` is taken as argument for the command that's executed. The command that's tested now sees the test- flags as arguments (`-test.v -test.run ..`), which causes various tests to fail ("Command XYZ does not accept arguments"). # compile the tests: go test -c -o foo.test # execute the test: ./foo.test -test.v -test.run TestFoo === RUN TestFoo Error: "foo" accepts no arguments. The Cobra maintainers ran into the same situation, and for their own use have added a special case to ignore `os.Args` in these cases; https://github.com/spf13/cobra/blob/v1.8.1/command.go#L1078-L1083 args := c.args // Workaround FAIL with "go test -v" or "cobra.test -test.v", see #155 if c.args == nil && filepath.Base(os.Args[0]) != "cobra.test" { args = os.Args[1:] } Unfortunately, that exception is too specific (only checks for `cobra.test`), so doesn't automatically fix the issue for other test-binaries. They did provide a `cmd.SetArgs()` utility for this purpose https://github.com/spf13/cobra/blob/v1.8.1/command.go#L276-L280 // SetArgs sets arguments for the command. It is set to os.Args[1:] by default, if desired, can be overridden // particularly useful when testing. func (c *Command) SetArgs(a []string) { c.args = a } And the fix is to explicitly set the command's args to an empty slice to prevent Cobra from falling back to using `os.Args[1:]` as arguments. cmd := newSomeThingCommand() cmd.SetArgs([]string{}) Some tests already take this issue into account, and I updated some tests for this, but there's likely many other ones that can use the same treatment. Perhaps the Cobra maintainers would accept a contribution to make their condition less specific and to look for binaries ending with a `.test` suffix (which is what compiled binaries usually are named as). Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2024-07-03 19:29:04 -04:00
cmd.SetOut(io.Discard)
cmd.SetErr(io.Discard)
test.TerminatePrompt(ctx, t, cmd, cli)
}