Over the previous few years, one factor has change into apparent to me: writing API checks is not the tough half.
Maintaining them helpful is.
Throughout totally different initiatives, I saved seeing the identical three issues seem repeatedly. None of them had been attributable to dangerous instruments or poor builders. They had been merely the results of APIs evolving sooner than the checks round them.
Listed here are the three adjustments that made the largest distinction for us.
1. Cease Treating Your API Specification as Documentation
For a very long time we maintained three totally different variations of the identical API:
- OpenAPI documentation
- Check circumstances
- Mock responses
Ultimately they drifted aside.
Somebody would replace the API however neglect to replace the checks.
Or the documentation.
Or the mocks.
As a substitute, we began treating the OpenAPI specification because the supply of fact.
The API adjustments as soon as.
Every thing else follows.
Even if you happen to aren’t producing checks robotically, having one canonical contract dramatically reduces upkeep.
2. Separate Contract Checks from Enterprise Checks
One mistake we made early was placing each assertion into the identical check.
For instance:
Create Buyer
↓
Standing = 201
↓
Schema Legitimate
↓
Enterprise Guidelines
↓
Database Validation
When the check failed, discovering the precise trigger took time.
As a substitute we now break up duties.
Contract checks
- Standing codes
- Headers
- Required fields
- Response schema
Enterprise checks
- Pricing
- Permissions
- Validation guidelines
- Workflows
The checks turned a lot simpler to grasp and far simpler to take care of.
3. Do not Mock Every thing
For some time we mocked each exterior dependency.
The check suite was quick.
It was additionally overconfident.
Ultimately we found that a number of manufacturing failures had been attributable to assumptions our mocks by no means exercised.
At the moment we use three layers.
- **Unit checks – **Mock all the things.
- **Integration checks – **Mock solely programs we do not management.
- **Pre-release validation – **Run a small suite in opposition to actual companies or official sandbox environments.
It is slower, nevertheless it catches points that good mocks by no means will.
One Lesson I Did not Anticipate
Authentication checks now eat extra CI time than virtually the rest.
OAuth flows, token refresh, service accounts, rotating secrets and techniques… they’re all vital, however they’re additionally costly to check correctly.
I am curious how different groups are dealing with this at the moment.
Are you:
- Testing in opposition to an actual id supplier?
- Working an area mock?
- Utilizing pre-generated tokens?
- Doing one thing fully totally different?
I would additionally have an interest to listen to the way you’re approaching cursor-based pagination and testing third-party APIs e.g. Stripe or Twilio, and so forth.
Each workforce appears to have a unique reply, and I believe there is not a single “greatest” resolution.
