Читать книгу Practical Go - Amit Saha - Страница 60
Testing the Cmd Package
ОглавлениеTo test the cmd
package, you will define similar test cases. Here are the test cases for the TestHandleHttp()
function:
testConfigs := []struct { args []string output string err error }{ // Test behavior when the http sub-command is called with no // positional argument specified { args: []string{}, err: ErrNoServerSpecified, }, // Test behavior when the http sub-command is called with "-h" { args: []string{"-h"}, err: errors.New("flag: help requested"), output: usageMessage, }, // Test behavior when the http sub-command is called // with a positional argument specifying the server URL { args: []string{"http://localhost"}, err: nil, output: "Executing http command\n", }, }
You can find the complete test in chap2/sub-cmd-arch/cmd/handle_http_test.go
.
The test configurations for the TestHandleGrpc()
function are as follows:
testConfigs := []struct { args []string err error output string }{ // Test behavior when the grpc sub-command is called with no // positional argument specified { args: []string{}, err: ErrNoServerSpecified, }, // Test behavior when the grpc sub-command is called with "-h" { args: []string{"-h"}, err: errors.New("flag: help requested"), output: usageMessage, }, // Test behavior when the http sub-command is called // with a positional argument specifying the server URL { args: []string{"-method", "service.host.local/method", "-body", "{}", "http://localhost"}, err: nil, output: "Executing grpc command\n", }, }
You can find the complete test in chap2/sub-cmd-arch/cmd/handle_grpc_test.go
.
The source tree for the application should now look like the following:
. |____cmd | |____grpcCmd.go | |____handle_grpc_test.go | |____handle_http_test.go | |____httpCmd.go | |____errors.go |____handle_command_test.go |____go.mod |____main.go
From the root of the module, run all of the tests:
$ go test -v ./… === RUN TestHandleCommand --- PASS: TestHandleCommand (0.00s) PASS ok github.com/practicalgo/code/chap2/sub-cmd-arch 0.456s === RUN TestHandleGrpc --- PASS: TestHandleGrpc (0.00s) === RUN TestHandleHttp --- PASS: TestHandleHttp (0.00s) PASS ok github.com/practicalgo/code/chap2/sub-cmd-arch/cmd 0.720s
Great. You now have unit tests for both the packages. You have written a test to verify that the main
package displays an error when an empty or invalid sub-command is specified and calls the right sub-command when a valid sub-command is specified. You have also written a test for the cmd
package to verify that the sub-command implementations behave as expected.
In Exercise 2.2, you will add a validation to the http
sub-command to allow only three HTTP methods: GET
, POST
, and HEAD
.
EXERCISE 2.2: HTTP METHOD VALIDATOR You will add validation to the http
sub-command in this exercise. You will ensure that the method option only allows three values: GET
(the default), POST
, and HEAD
.
If the method yields anything other than these values, the program should exit with a non-zero exit code and print the error “Invalid HTTP method”. Write tests to verify the validation.
In this section, you learned how to write a command-line application with sub-commands. When you are writing a large command-line application, organizing the functionality into separate sub-commands improves the user experience. Next, you will learn how to implement a degree of predictability and robustness in command-line applications.