Читать книгу 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.

Practical Go

Подняться наверх