API and Database Testing

🧪 Specialized Testing: API and Database Testing

Break It Before Users Do!

🎭 The Restaurant Kitchen Story

Imagine a busy restaurant. The kitchen (backend) makes food. The waiters (APIs) take orders and bring food to tables. The pantry (database) stores all ingredients.

If waiters forget orders, or the pantry has spoiled food, customers get angry!

API and Database Testing = Making sure waiters never mess up orders, and the pantry always has fresh, organized ingredients.

📡 API Testing Overview

What is an API?

Think of an API like a waiter in a restaurant.

• You (the app) tell the waiter: “I want pizza!”
• The waiter goes to the kitchen (server)
• The kitchen makes pizza
• The waiter brings it back to you

API = The messenger between you and the kitchen

Why Test APIs?

What could go wrong?
━━━━━━━━━━━━━━━━━━━━
❌ Waiter forgets your order
❌ Waiter brings wrong food
❌ Waiter takes too long
❌ Kitchen is closed

API Testing checks:

• ✅ Does the waiter understand my order?
• ✅ Does the waiter bring the right food?
• ✅ Does the waiter reply fast enough?
• ✅ What happens if I order something weird?

Simple Example

You send: GET /users/123
You expect: { "name": "Alice", "age": 25 }

Test checks:
✓ Status code = 200 (success)
✓ Response has "name" field
✓ Response time < 2 seconds

🔌 API Protocol Testing

What’s a Protocol?

A protocol = Rules for how to talk.

Like different languages:

• REST = Simple English (most common)
• GraphQL = Custom order form (ask exactly what you want)
• SOAP = Formal letter (old-fashioned, strict)
• gRPC = Super fast walkie-talkie

REST API Testing

REST uses simple words like:

• GET = “Give me something”
• POST = “Here’s something new”
• PUT = “Update this thing”
• DELETE = “Remove this thing”

Testing a REST API:
━━━━━━━━━━━━━━━━━━━
GET /toys → Should list all toys
POST /toys → Should create new toy
PUT /toys/5 → Should update toy #5
DELETE /toys/5 → Should remove toy #5

GraphQL Testing

GraphQL is like a custom menu. You ask for exactly what you want!

Query: "Give me user name and email only"
{
  user(id: 1) {
    name
    email
  }
}

Response: Only name and email (nothing extra!)

Test checks: Did I get exactly what I asked for?

📝 Contract Testing

The Promise Between Friends

Imagine you and your friend have a promise:

“When I say ‘high-five’, you raise your hand.”

Contract = A written promise of how APIs will behave.

Why Contract Testing Matters

graph TD
    A["Team A: Makes API"] -->|Promise| C["Contract"]
    B["Team B: Uses API"] -->|Expects| C
    C -->|Both agree on| D["Request Format"]
    C -->|Both agree on| E["Response Format"]

Problem without contracts:

• Team A changes the API
• Team B’s app breaks
• Everyone is surprised and angry!

With contract testing:

• Both teams agree on the “promise”
• If anyone breaks the promise, tests fail immediately
• No surprises!

Simple Contract Example

Contract: GET /user/1 must return:
{
  "id": number (required),
  "name": string (required),
  "email": string (required)
}

If API returns something different → TEST FAILS!

🏗️ Microservices Testing

What Are Microservices?

Instead of one giant robot doing everything, you have many small robots, each doing one job.

Monolith (One Robot):
🤖 Does: Login + Orders + Payments + Emails

Microservices (Team of Robots):
👤 Login Robot
📦 Orders Robot
💳 Payments Robot
✉️ Email Robot

Why Test Microservices?

The small robots need to talk to each other.

graph TD
    A["👤 Login"] -->|Token| B["📦 Orders"]
    B -->|Order Info| C["💳 Payments"]
    C -->|Success| D["✉️ Email"]

What could go wrong?

• One robot is sleeping (service down)
• Robots speak different languages (format mismatch)
• Message gets lost in the middle

Testing Types for Microservices

Example Test

Scenario: User places an order

1. Login service → returns token ✓
2. Order service → creates order ✓
3. Payment service → charges card ✓
4. Email service → sends confirmation ✓

All robots worked together = TEST PASSED!

🗄️ Database Testing

The Pantry of Your App

The database is like a giant pantry that stores everything:

• User information (names, passwords)
• Orders
• Products
• Messages

Why Test the Database?

What if the pantry:
❌ Loses ingredients (data loss)
❌ Mixes up labels (wrong data)
❌ Is too slow to find things
❌ Lets anyone in (security hole)

What Database Testing Checks

✅ Can we save data correctly?
✅ Can we find data quickly?
✅ Is data protected from strangers?
✅ Does data stay safe when things crash?

Example: CRUD Testing

CRUD = Create, Read, Update, Delete (the 4 basic actions)

-- CREATE: Add new toy
INSERT INTO toys (name) VALUES ('Teddy');
→ Check: Did toy appear in database?

-- READ: Find the toy
SELECT * FROM toys WHERE name='Teddy';
→ Check: Did we get the right toy?

-- UPDATE: Rename the toy
UPDATE toys SET name='Mr. Teddy' WHERE id=1;
→ Check: Is the name changed?

-- DELETE: Remove the toy
DELETE FROM toys WHERE id=1;
→ Check: Is the toy gone?

🔒 Data Integrity Testing

Keeping Data Clean and Honest

Data Integrity = Data is correct, complete, and trustworthy.

Like making sure:

• Your piggy bank count is accurate
• No one secretly added or removed coins
• The total always makes sense

Types of Data Integrity

🔑 Entity Integrity
   Every row has a unique ID
   Example: No two users have same ID

🔗 Referential Integrity
   Relationships make sense
   Example: Order can't belong to
   a user that doesn't exist

✅ Domain Integrity
   Data follows rules
   Example: Age can't be negative

🧮 User-Defined Integrity
   Your custom rules
   Example: Discount can't exceed 50%

Testing Data Integrity

Test 1: Unique IDs
→ Try to create two users with same ID
→ Database should say NO!

Test 2: Required Fields
→ Try to save user without email
→ Database should say NO!

Test 3: Valid Values
→ Try to set age = -5
→ Database should say NO!

Example

-- This should FAIL (no duplicate emails!)
INSERT INTO users (email) VALUES ('bob@mail.com');
INSERT INTO users (email) VALUES ('bob@mail.com');
→ Error: Duplicate entry! ✓

-- This should FAIL (age must be positive!)
INSERT INTO users (age) VALUES (-10);
→ Error: Check constraint failed! ✓

🚚 Data Migration Testing

Moving to a New House

Data Migration = Moving data from old place to new place.

Like moving from an old house to a new house:

• Did all furniture arrive?
• Is everything in the right room?
• Did anything break during the move?

When Do We Migrate Data?

📦 Upgrading database version
📦 Switching to new database system
📦 Merging two companies' data
📦 Moving to cloud
📦 Splitting one database into many

What Migration Testing Checks

graph TD
    A["Old Database"] -->|Migrate| B["New Database"]
    C["Test: Count Records"] --> D{Same Count?}
    D -->|Yes| E["✅ Pass"]
    D -->|No| F["❌ Fail"]
    G["Test: Compare Data"] --> H{Same Values?}
    H -->|Yes| E
    H -->|No| F

Testing Checklist

Example Migration Test

OLD DATABASE (MySQL):
users table: 10,000 records

NEW DATABASE (PostgreSQL):
users table: ??? records

MIGRATION TEST:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✓ Count: 10,000 = 10,000 ✅
✓ Sample user #1 data matches ✅
✓ Sample user #5000 data matches ✅
✓ All emails still unique ✅
✓ Foreign keys still work ✅

MIGRATION SUCCESSFUL! 🎉

🎯 Quick Summary

┌─────────────────────────────────────────┐
│  API & DATABASE TESTING CHEAT SHEET    │
├─────────────────────────────────────────┤
│                                         │
│  🍽️ API = Waiter between you & kitchen │
│                                         │
│  📡 Protocol = Language APIs speak      │
│     (REST, GraphQL, SOAP, gRPC)        │
│                                         │
│  📝 Contract = Promise between teams    │
│                                         │
│  🏗️ Microservices = Team of small robots│
│                                         │
│  🗄️ Database = The pantry of your app  │
│                                         │
│  🔒 Data Integrity = Keep data clean   │
│                                         │
│  🚚 Migration = Moving to new house    │
│                                         │
└─────────────────────────────────────────┘

🚀 You’ve Got This!

Remember:

• APIs are just messengers - test that messages arrive correctly
• Databases are just storage - test that nothing gets lost or corrupted
• Always test before users find problems!

Happy Testing! 🧪✨