Test Server Laravel Package

Getting Started

This package is not for application development—it’s a minimal HTTP test server used exclusively by the Requests library’s internal test suite. As a Laravel developer, you’ll almost never need it. Only consider if you’re:

• Contributing bug fixes or features to the Requests library itself (e.g., updating its HTTP transports).
• Reproducing exact test scenarios from Requests’s test suite for debugging.

To start:

1. Clone the repo: git clone https://github.com/RequestsPHP/test-server.git
2. Run composer install (requires Composer ≥2.2).
3. Start the server manually: php server.php (default port: 8888).
4. Verify with: curl -v http://localhost:8888/status/200.

💡 Reality check: Laravel apps use Guzzle (not Requests) for HTTP. Use Http::fake() instead—it’s built-in, expressive, and far more powerful.

Implementation Patterns

• Only in Requests test runners: If you’re hacking on Requests, integrate test-server into your test bootstrap via phpunit.xml:

  <phpunit bootstrap="vendor/requestsphp/test-server/server.php">
  

  (Note: This is illustrative—actual usage is handled by Requests’s own CI scripts.)
• Simulating low-level HTTP edge cases: When testing Requests transports (e.g., cURL vs. stream), hit prebaked endpoints like:
  • http://localhost:8888/delay/3 → 3-second delay
  • http://localhost:8888/status/418 → I’m a teapot response
  • http://localhost:8888/timeout → Simulated timeout
• Never for app testing: For Laravel, use Http::fake() or Mockery to stub HTTP responses. This server offers no advantage—and is significantly more fragile.

Gotchas and Tips

• Zero integration with Laravel: No facades, service providers, or config. It’s a raw PHP server file with no lifecycle hooks.
• Hardcoded port 8888: Conflicts with other services (e.g., Docker, Valet). Kill any existing process: lsof -i :8888 | grep LISTEN | awk '{print $2}' | xargs kill.
• No graceful shutdown: Ctrl+C doesn’t clean up cleanly. Manually kill the process: pkill -f server.php.
• Fragile in CI: Works on Linux/macOS but often fails on Windows due to stream_socket_server() limitations or missing php_cli_server support.
• Security risk if misused: Lacks SSL, auth, or request sanitization. Never expose it externally—even temporarily.
• When tests fail: Check if server.php is still running (ps aux | grep server.php). If curl hits it but your test doesn’t, the issue is likely your client’s timeout or timeout configuration—not the server.