An integration test checks whether units of software work together, often across an external dependency such as a database. It sits above fast, isolated unit tests and below broader end-to-end tests, so it provides useful system feedback without making the entire test suite expensive or unpredictable. section 3.4
Use integration tests to:
- Verify interactions that simulated external integrations cannot validate. section 9.1
- Check the user experience across connected components rather than only one module. section 9.1
- Run broader tests after unit tests pass, keeping failures easier to isolate. section 3.4
Moving translations from a client to a database
A translation service can retain its existing interface while configuration selects an external client, a database, or a hybrid fallback. First test the existing behavior, then connect the database and add integration tests that verify the resulting user experience and feature requirements. section 9.0 section 9.1
Figure 3.2 End-to-end tests are smaller at the top because they are more expensive and not as dependable. They should be supported by larger suites of integration and unit tests. Each layer should run on its own. Start with unit tests and progress up the pyramid in different phases.
Use the testing pyramid to place integration tests between larger unit-test suites and smaller, more expensive end-to-end suites. section 3.4
Listing 9.1 core.go
type Configuration struct {
Port string `json:"port"`
DefaultLanguage string `json:"default_language"`
LegacyEndpoint string `json:"legacy_endpoint"`
DatabaseURL string `json:"database_url"` #1
DatabasePort string `json:"database_port"` #2
}
Inspect the configuration fields that enable a database connection while preserving the option to use the legacy endpoint. section 9.1
