There are many types of tests in software development. The easiest way to understand them is by looking at what part of the system they test.
A common hierarchy is:
Tests
|
┌──────────────┼──────────────┐
↓ ↓ ↓
Unit Tests Integration End-to-End
Tests Tests1. Unit Test
A unit test tests the smallest piece of code independently.
A unit test might be weak because it only checks a part and maybe there is something else that is causing the bug on that part and the unit test wouldn’t know.
Usually:
-
a function
-
a class
-
a method
-
a component
The goal:
“Does this small piece of logic work correctly?”
Example
You have:
function calculateTotal(price, tax) {
return price + tax;
}Unit test:
expect(calculateTotal(100, 10))
.toBe(110);You are not testing:
-
database
-
API
-
frontend
-
network
Only the function.
Backend example
Service:
function isAdmin(user) {
return user.role === "ADMIN";
}Test:
Input:
{
role: "ADMIN"
}
Expected:
trueAdvantages
✅ Fast
✅ Easy to debug
✅ Finds logic bugs early
Disadvantages
❌ Does not prove the whole system works
2. Integration Test
An integration test checks whether multiple parts work together.
Example:
Controller
↓
Service
↓
DatabaseYou test the connection between them.
Example:
Your API:
POST /usersIntegration test:
Send request
↓
Controller receives it
↓
Service creates user
↓
Database stores user
↓
Response returnsExpected:
{
"id": 1,
"username": "reyhan"
}You are testing:
-
routes
-
middleware
-
services
-
database interaction
Example tools
Backend:
-
Supertest
-
Jest
-
pytest
Frontend:
-
React Testing Library
-
Vue Test Utils
3. End-to-End (E2E) Test
An E2E test tests the entire system like a real user.
It starts from the UI.
Example:
User registration:
Browser
↓
Open website
↓
Fill registration form
↓
Click Register
↓
Frontend sends API request
↓
Backend creates user
↓
Database saves user
↓
User sees dashboardThe test checks the whole journey.
Example:
Open /register
Type:
email=test@test.com
password=123456
Click submit
Expect:
Dashboard appearsTools:
-
Playwright
-
Cypress
-
Selenium
Advantages
✅ Tests real user behavior
Disadvantages
❌ Slow
❌ More fragile
4. API Test
Tests your API endpoints directly.
Example:
POST /api/loginTest:
Request:
{
"email": "test@test.com",
"password": "123"
}Response:
{
"token": "abc123"
}Checks:
-
status codes
-
response format
-
authentication
-
validation
Tools:
-
Postman
-
Bruno
-
Supertest
5. Component Test (Frontend)
Tests a UI component independently.
Example:
Component:
<Button text="Save" />Test:
Render button
Click button
Expect:
onClick calledYou don’t test the whole application.
Tools:
-
React Testing Library
-
Vue Test Utils
6. Regression Test
A regression test checks that old functionality still works after changes.
Example:
You add:
Feature:
Allow users to upload imagesA bug appears:
Login no longer worksYou fix it and add a regression test:
Login should always workLater changes cannot break it silently.
Think:
“We had this bug before. Make sure it never comes back.”
7. Smoke Test
A smoke test checks if the basic system works.
Usually after deployment.
Example:
After deploying:
✓ Website opens
✓ API responds
✓ Database connects
✓ Login worksIt answers:
“Is the system alive?”
Not:
“Is every feature perfect?“
8. Sanity Test
Similar to smoke testing, but more focused.
Example:
You fix:
Task creation bugSanity test:
✓ Create task works
✓ Task appears in listYou don’t test everything.
9. Performance Test
Checks how the system behaves under load.
Examples:
100 users
1000 users
10000 usersMeasures:
-
response time
-
throughput
-
resource usage
Example:
GET /tasks
1000 requests/sec
Average response:
120msTools:
-
k6
-
JMeter
-
Gatling
10. Load Test
A type of performance test.
Question:
“Can the system handle expected traffic?”
Example:
Your app normally has:
500 users/minuteLoad test:
500 users/minute11. Stress Test
Pushes the system beyond normal limits.
Question:
“When does it break?”
Example:
Expected:
10,000 users
Test:
100,000 usersYou learn:
-
breaking point
-
failure behavior
-
recovery
A pressure test is usually another name people use for a stress test or load test, depending on the context.
In software, a pressure test means:
Putting the system under heavy pressure (high traffic, high data volume, or limited resources) to see how it behaves.
The goal is not only “does it work?” but:
-
When does it become slow?
-
When does it fail?
-
Does it recover?
-
Does it lose data?
-
Does it fail gracefully?
Example
Imagine your API normally handles:
1000 requests/minuteA pressure test might push it:
5000 requests/minute
10000 requests/minute
50000 requests/minuteYou observe:
Requests increase
↓
Response time increases
↓
CPU reaches 100%
↓
Errors start appearing
↓
System crashesYou find the breaking point.
Load test vs stress/pressure test
Load test
Tests expected usage.
Question:
“Can my system handle normal traffic?”
Example:
Expected users:
10,000
Test:
10,000 usersStress / pressure test
Tests beyond normal limits.
Question:
“How much can my system take before it breaks?”
Example:
Expected users:
10,000
Test:
100,000 usersExample for an API
Suppose you have:
POST /api/loginNormal:
100 login requests/secPressure test:
5000 login requests/secYou measure:
Response time:
100ms → 2s → 10s
CPU:
40% → 95%
Errors:
0% → 30%
Now you know the limit.
Things pressure tests reveal
1. Bottlenecks
Example:
API server
↓
Database
↓
Database becomes slowThe problem is not the API server; it’s the database.
2. Resource limits
Example:
Memory:
4GB → 8GB → 16GBYour app may have a memory leak.
3. Failure behavior
A good system should fail gracefully:
Bad:
Traffic spike
↓
Everything crashesBetter:
Traffic spike
↓
Some requests rejected
↓
System stays aliveRelated terms
| Term | Meaning |
|---|---|
| Load test | Test expected traffic |
| Stress test | Push beyond expected limits |
| Pressure test | Usually stress test; informal term |
| Spike test | Sudden traffic increase |
| Soak test | Long-duration testing |
| Performance test | General category |
For backend/API systems, a common testing progression is:
Unit tests
↓
Integration tests
↓
API tests
↓
E2E tests
↓
Load tests
↓
Pressure/stress testsSo when someone says “pressure test the system”, they usually mean:
“Push it hard and find its limits.”
12. Security Test
Checks vulnerabilities.
Examples:
Testing:
-
SQL injection
-
authentication bypass
-
authorization problems
-
XSS
-
CSRF
Example:
Try:
DELETE /users/5as a normal user.
Expected:
403 Forbidden13. Contract Test
Checks that two services agree on communication.
Example:
Frontend expects:
{
"username": "reyhan"
}Backend accidentally changes:
{
"name": "reyhan"
}Contract test catches this.
Common in:
-
microservices
-
APIs
14. Acceptance Test
Checks whether the software satisfies business requirements.
Usually from the user’s perspective.
Example requirement:
“Admin users can delete projects.”
Acceptance test:
Given:
User is admin
When:
They delete a project
Then:
Project is removedSummary Table
| Test | Tests | Example |
|---|---|---|
| Unit | Small logic | Function calculation |
| Integration | Parts working together | API + DB |
| E2E | Full user flow | Register → Login → Dashboard |
| API | Backend endpoints | POST /login |
| Component | UI pieces | Button behavior |
| Regression | Old bugs stay fixed | Login remains working |
| Smoke | Basic health | App starts |
| Sanity | Specific fix | Task creation |
| Performance | Speed/capacity | Requests/sec |
| Load | Expected traffic | 10k users |
| Stress | Beyond limits | 100k users |
| Security | Vulnerabilities | Auth bypass |
| Contract | API agreement | Frontend/backend schema |
| Acceptance | Business requirements | User story works |
For a typical backend REST API project, the most important ones to learn first are:
-
Unit tests
-
Integration tests
-
API tests
-
E2E tests
-
Regression tests
-
Performance tests (later)