The actual test would look like this: public function testCanRequest201Response(): void 'client_builder' => new ClientBuilder($this->mockClient), abstract class TestCase extends \PHPUnit\Framework\TestCase This also means we reduce the boilerplate in our actual test cases. A simple way to do this is to add it as a property to our base TestCase and use that client in our givenSdk method. In order to do this, we’ll need to have access to our actual Mock\Client instance. This might not always be what you want, but we can leverage Mock Client to customize the response using the addResponse method.
#PHPUNIT API CODE#
In the test above we’re asserting that the response we get after doing a GET request has a status code of 200, which is the default response returned by Mock Client. $this->assertEquals(200, $response->getStatusCode()) $httpClient = $this->givenSdk()->getHttpClient() Public function testCanRequest200Response(): void Now that we’ve done preliminary work we can create our first test. The line above makes sure that Mock Client will always be used.
#PHPUNIT API SERIES#
To explain what this does we’ll do a little throwback to part 1 of this series where I explained that PHP-HTTP is able to discover a PSR-18 implementation. Require _DIR_.'/./vendor/autoload.php' ĬlassDiscovery::prependStrategy(MockClientStrategy::class) Use Http\Discovery\Strategy\MockClientStrategy We can configure this in our PHPUnit’s bootstrap file by adding the following lines: use Http\Discovery\ClassDiscovery The second thing we’ll do is make sure we default to use the Mock Client implementation so we do not accidentally send out a real HTTP request. In this case, I’m providing a givenSdk() method that will return an SDK instance: abstract class TestCase extends \PHPUnit\Framework\TestCase
The first test we will write will be a fairly simple one: we will retrieve the current HTTP client on the SDK and try to perform a GET request to a URL.įirst of all, we’ll create our own TestCase implementation that we can extend with our own methods to make common parts easier to execute.
#PHPUNIT API INSTALL#
The first step is to install the Mock Client dependency with composer: composer require -dev php-http/mock-client This client is essentially an in-memory implementation of an HTTP Client that collects the requests that are performed but also allows faking responses. This is where the Mock Client package comes in. If we decide to refactor the internals of our SDK, we would have to refactor our tests as well. The downside of that approach is that this would heavily tie our tests to our implementation. To solve this, the first thing that comes to mind is that we should mock our HTTP client using PHPUnit’s mocks or Mockery.
However, we do not want our test suite to actually perform an HTTP request. In the context of our SDK this means that, given a certain set of parameters, we want to assert the correct HTTP request is being made. If our SDK offers methods to interact with an HTTP API, then those methods should be tested. The test suite of our SDK should be focused on the behaviour that it offers. In our last article we’ve looked at how we can make our SDK configurable and today we’ll apply this to cover our SDK with several unit tests. This post is part 3 of the “Building an SDK with PHP” series.
0 kommentar(er)
