Testing Strategy

The testing strategy for the zalopay project relies on Go's native testing framework, augmented with third-party assertion libraries. Testing is automated through a Continuous Integration (CI) pipeline using GitHub Actions and can be run locally using predefined Makefile commands. The strategy covers unit tests for individual packages and integration-style tests for HTTP handlers.

Continuous Integration (CI)

The project uses GitHub Actions for its CI pipeline to automatically build and test the code on every push or pull request to the main branch.

Sources: .github/workflows/go.yml:2-5

CI Workflow

The workflow, defined in go.yml, consists of a single job named build. This job executes the following steps:

1. Checkout Code: Checks out the repository's code.
2. Set up Go: Initializes the Go environment, currently using Go version 1.16.
3. Run tests: Executes all tests in the project recursively (./...) with verbose output (-v).

Sources: .github/workflows/go.yml:8-20

The following diagram illustrates the CI process defined in the GitHub Actions workflow.

Local Testing

Developers can run tests locally using the Makefile. This provides a consistent and simple way to execute the test suite.

Sources: Makefile

Test Command

The Makefile defines a test target that runs all tests and generates a coverage report.

Sources: Makefile:2-3

The local testing flow is straightforward:

Testing Framework and Libraries

The project uses Go's standard testing package along with helper libraries for assertions and HTTP testing.

Dependencies

The primary testing dependency is testify, which provides assertion and mocking capabilities.

Sources: go.mod:13, main_test.go:9, payment/payment_test.go:7

Test Implementation

Tests are located alongside the source code in _test.go files, following standard Go conventions. The tests cover different layers of the application, from business logic in packages to HTTP handlers in the main application.

HTTP Endpoint Testing

The main_test.go file demonstrates how HTTP endpoints are tested. It uses the standard library's net/http/httptest package to create a mock HTTP server, allowing tests to be run without needing to stand up the full application.

The TestCreateOrder function tests the order creation endpoint. It performs the following steps:

1. Defines a test server using httptest.NewServer.
2. Creates a new HTTP POST request with a JSON body.
3. Executes the request against the test server.
4. Uses assert.Equal to verify the HTTP status code is 200 OK.

Sources: main_test.go:12-32

The sequence diagram below shows the interaction for testing the /order/create endpoint.

Package Unit Testing

Packages like payment and provider have their own unit tests to validate business logic in isolation.

Payment Package

TestCreateOrder in payment/payment_test.go tests the CreateOrder function. It calls the function with a sample Order struct and asserts that the return_code is 1 and the return_message is "Success". This validates the success path of the order creation logic within the payment package.

Sources: payment/payment_test.go:10-23

Provider Package

TestGetBankList in provider/provider_test.go tests the GetBankList function. It calls the function and asserts that the result is not nil and that no error is returned, ensuring the bank list retrieval logic functions correctly.

Sources: provider/provider_test.go:9-14

Summary

The testing strategy in zalopay is comprehensive, covering both automated CI and local execution. It leverages standard Go tooling (go test, httptest) and the popular testify library for robust assertions. Tests are structured to validate both isolated business logic within packages and the integrated behavior of HTTP endpoints, ensuring code quality and reliability. The inclusion of coverage analysis in the local test script indicates an awareness of test completeness.