Bird
Raised Fist0
Expressframework~8 mins

Mocking database calls in Express - Performance & Optimization

Choose your learning style10 modes available
Performance: Mocking database calls
MEDIUM IMPACT
This concept affects server response time and user experience by reducing delays caused by real database queries during development and testing.
Testing API endpoints without hitting the real database
Express
const mockUsers = [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }];
app.get('/users', async (req, res) => {
  res.json(mockUsers);
});
Returns data instantly without waiting for database, improving test speed and reliability.
📈 Performance Gainresponse time reduced to <1ms, no DB wait
Testing API endpoints without hitting the real database
Express
app.get('/users', async (req, res) => {
  const users = await db.query('SELECT * FROM users');
  res.json(users);
});
This calls the real database on every request, causing slow responses and possible test flakiness.
📉 Performance Costblocks response for 50-200ms per request depending on DB speed
Performance Comparison
PatternDOM OperationsReflowsPaint CostVerdict
Real DB call on each requestN/A (server-side)N/AN/A[X] Bad
Mocked DB call with static dataN/A (server-side)N/AN/A[OK] Good
Rendering Pipeline
Mocking database calls bypasses the backend database query stage, allowing the server to respond faster. This reduces the time before the browser receives data and can render content.
→Server Processing
→Network Transfer
→Browser Rendering
⚠️ BottleneckServer Processing (database query time)
Core Web Vital Affected
INP
This concept affects server response time and user experience by reducing delays caused by real database queries during development and testing.
Optimization Tips
1Mock database calls to avoid slow real queries during development and testing.
2Use static or in-memory data to speed up API responses.
3Faster API responses improve user interaction responsiveness (INP).
Performance Quiz - 3 Questions
Test your performance knowledge
Why does mocking database calls improve API response times during development?
ABecause it compresses the network data
BBecause it reduces the size of the database
CBecause it avoids waiting for slow database queries
DBecause it caches the browser rendering
DevTools: Network
How to check: Open DevTools, go to Network tab, make the API request, and check the response time.
What to look for: Look for faster response times (<1ms) when mocking versus slower times (50ms+) with real DB calls.

Practice

(1/5)
1. What is the main purpose of mocking database calls in Express applications?
easy
A. To test code without needing a real database connection
B. To speed up the database queries in production
C. To permanently replace the database with fake data
D. To make the database store data faster

Solution

  1. Step 1: Understand mocking concept

    Mocking means creating fake versions of parts of your app, like database calls, to test without real dependencies.
  2. Step 2: Identify the purpose in testing

    Mocking database calls allows testing code logic without needing a real database, making tests faster and more reliable.
  3. Final Answer:

    To test code without needing a real database connection -> Option A
  4. Quick Check:

    Mocking = Test without real DB [OK]
Hint: Mocking means faking DB calls to test code fast [OK]
Common Mistakes:
  • Thinking mocking speeds up production DB
  • Confusing mocking with permanent DB replacement
  • Assuming mocking changes real data storage
2. Which of the following is the correct way to mock a database call returning a promise in Express?
easy
A. const mockDbCall = Promise.resolve({ id: 1, name: 'Test' });
B. const mockDbCall = () => { return { id: 1, name: 'Test' }; };
C. const mockDbCall = () => new Promise({ id: 1, name: 'Test' });
D. const mockDbCall = () => Promise.resolve({ id: 1, name: 'Test' });

Solution

  1. Step 1: Understand promise returning function

    A mock database call should return a promise that resolves to data, so Promise.resolve is correct.
  2. Step 2: Check each option

    const mockDbCall = Promise.resolve({ id: 1, name: 'Test' }); assigns a resolved promise directly, making mockDbCall a promise object not a callable function. const mockDbCall = () => { return { id: 1, name: 'Test' }; }; returns plain object, not a promise. const mockDbCall = () => Promise.resolve({ id: 1, name: 'Test' }); returns a function returning a resolved promise, correct. const mockDbCall = () => new Promise({ id: 1, name: 'Test' }); incorrectly uses new Promise without executor function.
  3. Final Answer:

    const mockDbCall = () => Promise.resolve({ id: 1, name: 'Test' }); -> Option D
  4. Quick Check:

    Promise.resolve returns a resolved promise [OK]
Hint: Use Promise.resolve to return mock data as a promise [OK]
Common Mistakes:
  • Returning plain object instead of a promise
  • Using new Promise without executor function
  • Assigning a promise directly instead of a function returning it
3. Given the mock function below, what will getUser().then(console.log) output?
const getUser = () => Promise.resolve({ id: 5, name: 'Alice' });
medium
A. { id: 5, name: 'Alice' }
B. Promise { { id: 5, name: 'Alice' } }
C. undefined
D. Error: getUser is not a function

Solution

  1. Step 1: Understand the mock function

    getUser returns a promise resolved with an object { id: 5, name: 'Alice' }.
  2. Step 2: Analyze the .then(console.log) call

    The .then method receives the resolved value and logs it, so the output is the object itself.
  3. Final Answer:

    { id: 5, name: 'Alice' } -> Option A
  4. Quick Check:

    Promise resolves to object logged [OK]
Hint: Promise.then logs resolved value, not the promise itself [OK]
Common Mistakes:
  • Thinking console.log prints the promise object
  • Expecting undefined because of missing await
  • Assuming getUser is undefined or error
4. Identify the error in this mock database call function:
function fetchData() {
  return new Promise(data => {
    resolve({ id: 1, value: 'mock' });
  });
}
medium
A. The function should be async instead of returning a promise
B. The promise executor function parameter should be (resolve, reject), not (data)
C. The data object is missing a required field
D. The function should not return a promise

Solution

  1. Step 1: Review Promise constructor usage

    The Promise constructor expects an executor function with two parameters: resolve and reject.
  2. Step 2: Identify misuse of parameter

    The code declares executor parameter as 'data' but calls resolve(...), where resolve is undefined. It should declare (resolve, reject) and call resolve(value).
  3. Final Answer:

    The promise executor function parameter should be (resolve, reject), not (data) -> Option B
  4. Quick Check:

    Promise executor = (resolve, reject) [OK]
Hint: Promise executor needs (resolve, reject) parameters [OK]
Common Mistakes:
  • Using wrong parameter name in Promise executor
  • Not returning a promise for async behavior
  • Confusing async function with Promise constructor
5. You want to mock a database call in Express that sometimes returns data and sometimes throws an error to test error handling. Which mock function correctly simulates this behavior?
hard
A. const mockDb = () => Promise.resolve({ id: 1 });
B. const mockDb = () => { if (Math.random() > 0.5) return { id: 1 }; else throw new Error('DB error'); };
C. const mockDb = () => Math.random() > 0.5 ? Promise.resolve({ id: 1 }) : Promise.reject(new Error('DB error'));
D. const mockDb = () => new Promise((resolve) => resolve({ id: 1 }));

Solution

  1. Step 1: Understand requirement for success and failure

    The mock must sometimes resolve with data and sometimes reject with an error to test both cases.
  2. Step 2: Analyze each option

    const mockDb = () => Math.random() > 0.5 ? Promise.resolve({ id: 1 }) : Promise.reject(new Error('DB error')); returns a promise that resolves or rejects based on random chance, correctly simulating success or failure.
    const mockDb = () => { if (Math.random() > 0.5) return { id: 1 }; else throw new Error('DB error'); }; throws error synchronously, not returning a promise rejection.
    const mockDb = () => Promise.resolve({ id: 1 }); always resolves, no error simulation.
    const mockDb = () => new Promise((resolve) => resolve({ id: 1 })); always resolves, no error simulation.
  3. Final Answer:

    const mockDb = () => Math.random() > 0.5 ? Promise.resolve({ id: 1 }) : Promise.reject(new Error('DB error')); -> Option C
  4. Quick Check:

    Random resolve or reject simulates success/error [OK]
Hint: Use Promise.resolve or Promise.reject to simulate success or error [OK]
Common Mistakes:
  • Throwing error instead of rejecting promise
  • Always resolving without error case
  • Not returning a promise for async simulation
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard