PHP From ZeroModern PHP course

testing php applications

Testing Web Requests

HTTP tests exercise an application through request and response boundaries without driving a real browser. They are well suited to routing, validation, authentication, authorisation, JSON shapes, redirects, and status codes.

Assert The Contract

A useful API test sends a realistic request and checks status, headers, and a small stable response shape. For HTML routes, check the redirect, important text, or persisted effect rather than every byte of markup.

Include Rejected Requests

Important endpoints need anonymous, unauthorised, malformed, and missing-record cases. These failures often reveal more production risk than the first happy-path test.

For GET /api/products/42, assert a 200 status and stable fields such as id and name. For GET /api/products/999999, assert a 404 status and the application's public error shape. If the route is private, add anonymous and unauthorized cases.

Common Mistakes

  • Checking only 200 responses.
  • Asserting full unstable response bodies.
  • Skipping authentication and ownership cases.
  • Confusing HTTP tests with browser tests.

What To Practise

  • Test status codes and stable response shapes.
  • Cover rejected requests.
  • Use HTTP tests before adding expensive browser checks.

Practice

Practice: Check A Product Endpoint

Plan HTTP tests for GET /api/products/{id}.

Requirements

  • Cover found and missing products.
  • Check status and stable JSON fields.
  • Include an authentication case if the endpoint is private.
  • Avoid brittle whole-response assertions.
Show solution

The response contract is small and explicit.

  • Request a known product and assert 200, its id, and its name.
  • Request an unknown product and assert 404 plus the stable public error field.
  • If the endpoint is private, request it anonymously and assert 401.

A framework test client would make the real request and assert these outcomes.