Skip to content
A set of abstractions extracted out of the Symfony components
Branch: master
Clone or download
fabpot feature #30604 [HttpClient] add MockHttpClient (nicolas-grekas)
This PR was merged into the 4.3-dev branch.


[HttpClient] add MockHttpClient

| Q             | A
| ------------- | ---
| Branch?       | master
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | -
| License       | MIT
| Doc PR        | -

This PR introduces `MockHttpClient` and `MockResponse`, to be used for testing classes that need an HTTP client without making actual HTTP requests.

`MockHttpClient` is configured via its constructor: you provide it either with an iterable or a callable, and these will be used to provide responses as the consumer requests them.

$responses = [
    new MockResponse($body1, $info1),
    new MockResponse($body2, $info2),

$client = new MockHttpClient($responses);
$response1 = $client->request(...); // created from $responses[0]
$response2 = $client->request(...); // created from $responses[1]

Or alternatively:
$callback = function ($method, $url, $options) {
    return new MockResponse(...);

$client = new MockHttpClient($callback);
$response = $client->request(...); // calls $callback internal

The responses provided to the client don't have to be instances of `MockResponse` - any `ResponseInterface` works (e.g. `$this->getMockBuilder(ResponseInterface::class)->getMock()`).

Using `MockResponse` allows simulating chunked responses and timeouts:
$body = function () {
    yield 'hello';
    yield ''; // the empty string is turned into a timeout so that they are easy to test
    yield 'world';
$mockResponse = new Mockresponse($body);

Last but not least, the implementation simulates the full lifecycle of a properly behaving `HttpClientInterface` contracts implementation: error handling, progress function, etc. This is "proved" by `MockHttpClientTest`, who implements and passes the reference test suite in `HttpClientTestCase`.


8fd7584158 [HttpClient] add MockHttpClient
Latest commit a4f68e9 Mar 20, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
Cache fixed CS Jan 16, 2019
HttpClient feature #30604 [HttpClient] add MockHttpClient (nicolas-grekas) Mar 19, 2019
Service fixed CS Jan 16, 2019
Tests fixed CS Jan 16, 2019
Translation fixed CS Jan 16, 2019
LICENSE [Contracts] clarify the README Nov 21, 2018
composer.json [Contracts] introduce HttpClient contracts Mar 7, 2019

Symfony Contracts

A set of abstractions extracted out of the Symfony components.

Can be used to build on semantics that the Symfony components proved useful - and that already have battle tested implementations.

Design Principles

  • contracts are split by domain, each into their own sub-namespaces;
  • contracts are small and consistent sets of PHP interfaces, traits, normative docblocks and reference test suites when applicable, etc.;
  • all contracts must have a proven implementation to enter this repository;
  • they must be backward compatible with existing Symfony components.

Packages that implement specific contracts should list them in the "provide" section of their "composer.json" file, using the symfony/*-contracts-implementation convention (e.g. "provide": { "symfony/cache-contracts-implementation": "1.0" }).


How to use this package?

The abstractions in this package are useful to achieve loose coupling and interoperability. By using the provided interfaces as type hints, you are able to reuse any implementations that match their contracts. It could be a Symfony component, or another one provided by the PHP community at large.

Depending on their semantics, some interfaces can be combined with autowiring to seamlessly inject a service in your classes.

Others might be useful as labeling interfaces, to hint about a specific behavior that could be enabled when using autoconfiguration or manual service tagging (or any other means provided by your framework.)

How is this different from PHP-FIG's PSRs?

When applicable, the provided contracts are built on top of PHP-FIG's PSRs. But the group has different goals and different processes. Here, we're focusing on providing abstractions that are useful on their own while still compatible with implementations provided by Symfony. Although not the main target, we hope that the declared contracts will directly or indirectly contribute to the PHP-FIG.

Why isn't this package split into several packages?

Putting all interfaces in one package eases discoverability and dependency management. Instead of dealing with a myriad of small packages and the corresponding matrix of versions, you just need to deal with one package and one version. Also when using IDE autocompletion or just reading the source code, it makes it easier to figure out which contracts are provided.

There are two downsides to this approach: you may have unused files in your vendor/ directory, and in the future, it will be impossible to use two different sub-namespaces in different major versions of the package. For the "unused files" downside, it has no practical consequences: their file sizes are very small, and there is no performance overhead at all since they are never loaded. For major versions, this package follows the Symfony BC + deprecation policies, with an additional restriction to never remove deprecated interfaces.


You can’t perform that action at this time.