Over the previous couple of years, one factor has turn out to be apparent to me: writing API exams is not the tough half.
Protecting them helpful is.
Throughout completely different tasks, I stored 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 exams round them.
Listed below are the three modifications that made the most important distinction for us.
1. Cease Treating Your API Specification as Documentation
For a very long time we maintained three completely different variations of the identical API:
- OpenAPI documentation
- Take a look at circumstances
- Mock responses
Ultimately they drifted aside.
Somebody would replace the API however overlook to replace the exams.
Or the documentation.
Or the mocks.
As an alternative, we began treating the OpenAPI specification because the supply of reality.
The API modifications as soon as.
The whole lot else follows.
Even for those who aren’t producing exams routinely, having one canonical contract dramatically reduces upkeep.
2. Separate Contract Exams from Enterprise Exams
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 an alternative we now cut up duties.
Contract exams
- Standing codes
- Headers
- Required fields
- Response schema
Enterprise exams
- Pricing
- Permissions
- Validation guidelines
- Workflows
The exams turned a lot simpler to grasp and far simpler to keep up.
3. Do not Mock The whole lot
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.
In the present day we use three layers.
- **Unit exams – **Mock all the things.
- **Integration exams – **Mock solely techniques we do not management.
- **Pre-release validation – **Run a small suite towards actual companies or official sandbox environments.
It is slower, but it surely catches points that excellent mocks by no means will.
One Lesson I Did not Anticipate
Authentication exams now eat extra CI time than virtually the rest.
OAuth flows, token refresh, service accounts, rotating secrets and techniques… they’re all obligatory, however they’re additionally costly to check correctly.
I am curious how different groups are dealing with this as we speak.
Are you:
- Testing towards an actual identification supplier?
- Working an area mock?
- Utilizing pre-generated tokens?
- Doing one thing utterly completely 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 many others.
Each workforce appears to have a distinct reply, and I believe there is not a single “finest” answer.
