Testing systematically evaluates software behavior against expected results or properties. In a microservice system, it isolates a service such as Order to provide faster feedback and reduce delivery cost compared with manually exercising the full flow. section 7.0 section 7.2
Select a strategy according to scope, feedback speed, and dependency cost:
- Use unit tests to verify scenarios within a service or module; favor them for fast feedback and lower infrastructure cost. section 7.6
- Use integration tests to verify that two modules work together, commonly testing a data layer against a real database. section 7.6
- Use end-to-end tests to verify a flow across all available services, accepting broader environment involvement. section 7.6
- Use mocks when real dependencies would slow feedback; use test containers when the real dependency is valuable to the integration test. section 7.2.2
Structure an automated test around four phases:
- Setup dependencies and initialize the system under test (SUT). section 7.2.2
- Invoke the SUT operation under test. section 7.2.2
- Verify actual and expected results with assertions. section 7.2.2
- Tear down resources that are no longer needed, such as a temporary database. section 7.2.2
Testing Fibonacci and Order
A Go test can call Fibonacci(3), expect 2, and verify the result with testify assertions in a _test.go file executed by go test. For an Order service backed by MySQL, either start a database through test containers or mock database calls when rapid feedback matters more. section 7.2.2 section 7.2.2
// math_test.go
package math
import (
"testing"
"github.com/stretchr/testify/assert" #1
)
func TestFibonacci(t *testing.T) {
actual := Fibonacci(3)
expected := 2
assert.Equal(t, actual, expected)
}
Browse the compact Go unit test that invokes Fibonacci and checks its expected result. section 7.2.2
