In software engineering, a Seam (seam) refers to a boundary in code that can be replaced, isolated, or independently verified. This concept gained widespread recognition through Michael Feathers’ book Working Effectively with Legacy Code.
Colloquially, a Seam is the “entry point” we choose when testing a system:
- Where data is fed in;
- Where results are observed;
- Which part is tested as a whole;
- Which internal implementation details can be ignored.
Example: Mini-program login
WeChat login code
↓
Authentication module
↓
Login success / Phone number binding required / Login failure
Here, the “authentication module” can serve as a test boundary:
- Input WeChat login credentials;
- Verify the returned login status and token;
- Ignore internal details—such as how many functions are used or how variables are named.
Common Seams
- Between the API request layer and business logic;
- Between the service layer and the database;
- Between the UI page and the state management module;
- Between third-party services and application code;
- Between the WeChat login interface and the authentication module.
Why Do We Need Seams?
Choosing appropriate test boundaries enables us to:
- Isolate databases, network calls, and third-party services;
- Make tests easier to write and debug;
- Avoid coupling tests to internal implementation details;
- Preserve existing tests even after code refactoring;
- Clearly define what each test is responsible for verifying.
Summary
A Seam is a boundary in code that can be isolated, replaced, or independently verified. It defines where input enters the system, where output is observed, and what scope the test covers.