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          Tests

1. 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:
true

Advantages

✅ 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

Database

You test the connection between them.


Example:

Your API:

POST /users

Integration test:

Send request

Controller receives it

Service creates user

Database stores user

Response returns

Expected:

{
 "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 dashboard

The test checks the whole journey.

Example:

Open /register
 
Type:
email=test@test.com
password=123456
 
Click submit
 
Expect:
Dashboard appears

Tools:

  • Playwright

  • Cypress

  • Selenium

Advantages

✅ Tests real user behavior

Disadvantages

❌ Slow
❌ More fragile


4. API Test

Tests your API endpoints directly.

Example:

POST /api/login

Test:

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 called

You 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 images

A bug appears:

Login no longer works

You fix it and add a regression test:

Login should always work

Later 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 works

It 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 bug

Sanity test:

✓ Create task works
✓ Task appears in list

You don’t test everything.


9. Performance Test

Checks how the system behaves under load.

Examples:

100 users
1000 users
10000 users

Measures:

  • response time

  • throughput

  • resource usage

Example:

GET /tasks
 
1000 requests/sec
 
Average response:
120ms

Tools:

  • 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/minute

Load test:

500 users/minute

11. Stress Test

Pushes the system beyond normal limits.

Question:

“When does it break?”

Example:

Expected:
10,000 users
 
Test:
100,000 users

You 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/minute

A pressure test might push it:

5000 requests/minute
10000 requests/minute
50000 requests/minute

You observe:

Requests increase

Response time increases

CPU reaches 100%

Errors start appearing

System crashes

You 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 users

Stress / pressure test

Tests beyond normal limits.

Question:

“How much can my system take before it breaks?”

Example:

Expected users:
10,000
 
Test:
100,000 users

Example for an API

Suppose you have:

POST /api/login

Normal:

100 login requests/sec

Pressure test:

5000 login requests/sec

You 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 slow

The problem is not the API server; it’s the database.


2. Resource limits

Example:

Memory:
4GB → 8GB → 16GB

Your app may have a memory leak.


3. Failure behavior

A good system should fail gracefully:

Bad:

Traffic spike

Everything crashes

Better:

Traffic spike

Some requests rejected

System stays alive

TermMeaning
Load testTest expected traffic
Stress testPush beyond expected limits
Pressure testUsually stress test; informal term
Spike testSudden traffic increase
Soak testLong-duration testing
Performance testGeneral category

For backend/API systems, a common testing progression is:

Unit tests

Integration tests

API tests

E2E tests

Load tests

Pressure/stress tests

So 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/5

as a normal user.

Expected:

403 Forbidden

13. 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 removed

Summary Table

TestTestsExample
UnitSmall logicFunction calculation
IntegrationParts working togetherAPI + DB
E2EFull user flowRegister → Login → Dashboard
APIBackend endpointsPOST /login
ComponentUI piecesButton behavior
RegressionOld bugs stay fixedLogin remains working
SmokeBasic healthApp starts
SanitySpecific fixTask creation
PerformanceSpeed/capacityRequests/sec
LoadExpected traffic10k users
StressBeyond limits100k users
SecurityVulnerabilitiesAuth bypass
ContractAPI agreementFrontend/backend schema
AcceptanceBusiness requirementsUser story works

For a typical backend REST API project, the most important ones to learn first are:

  1. Unit tests

  2. Integration tests

  3. API tests

  4. E2E tests

  5. Regression tests

  6. Performance tests (later)


Back-End My-Journey-In-Codeless