Error handling and boundary tests

A test suite that only verifies the happy path does not test the code that actually runs when things go wrong. ISO 25010:2011 §6.5.5 requires reliability verification to cover failure modes. Missing error-path tests mean: API 404 and 500 responses produce untested UI states that may crash or show stale data; invalid inputs reach business logic that was never verified to reject them correctly; catch blocks that silently swallow errors pass code review because no test ever triggered them.

Add at least one negative test per critical unit. A minimal pattern alongside each success test:

describe('fetchUser', () => {
  it('returns user data on success', async () => {
    mockFetch.mockResolvedValue({ id: '1', name: 'Alice' })
    const user = await fetchUser('1')
    expect(user.name).toBe('Alice')
  })

  it('throws UserNotFoundError when 404', async () => {
    mockFetch.mockRejectedValue(new Response(null, { status: 404 }))
    await expect(fetchUser('nonexistent')).rejects.toBeInstanceOf(UserNotFoundError)
  })

  it('handles null user id gracefully', async () => {
    await expect(fetchUser(null as unknown as string))
      .rejects.toThrow('User ID is required')
  })
})

Aim for at least 20% of tests to verify failure scenarios, not just success paths.