Skip to main content
Usability testing for a backend API means verifying that the API behaves correctly and predictably from the consumer’s perspective. This includes testing that error messages are meaningful, input validation rejects bad data with clear feedback, and behaviors like pagination work as documented. This page covers Postman, Newman, Supertest with a real MySQL test database, and Joi validation.

What Is API Usability Testing

For a backend API, usability testing answers:
  • Do endpoints return correct HTTP status codes in all cases?
  • Are error messages informative and consistent?
  • Is request validation comprehensive and helpful?
  • Does pagination, filtering, and sorting work as expected?
  • Do all documented endpoints behave as documented?
API usability testing sits between unit testing (mocked DB) and full E2E testing. It tests complete HTTP request-response cycles against the running application with a real test database.

Integration Testing vs Unit Testing

Postman: Manual API Testing

Creating a Collection

1

Create collection

Click Collections in sidebar, then + to create “SWDBD401 API Tests”.
2

Add folders per resource

Create folders: Auth, Users, Posts. Organize requests inside.
3

Set environment variables

Create an environment: baseUrl = http://localhost:3000, token = (empty initially).
4

Write test scripts

Add test scripts in the Tests tab of each request.

Postman Test Scripts

Newman: CLI Runner

MySQL Test Database Setup

Never run integration tests against your development or production database.

Database Seeding and Teardown

Supertest Integration Tests

Input Validation with Joi

Testing Error Response Quality

Key Terms

Common Mistakes

Tests truncate tables. Always use a separate DB_NAME_TEST database via .env.test and cross-env NODE_ENV=test.
If pool.end() is not called in afterAll, Jest hangs after tests complete because the pool keeps Node.js alive.
Usability testing must cover error paths: missing fields, duplicate emails, unauthorized access, not found IDs. Users always hit these paths.
Client input mistakes should return 400 or 422, not 500. A 500 hides the real cause and forces clients to guess what went wrong.