This package is abandoned and no longer maintained. The author suggests using the lchrusciel/api-test-case package instead.

Perfect PHPUnit TestCase for JSON/XML API TDD with Symfony.

v4.0.1 2019-03-04 13:37 UTC


Build Status Scrutinizer Code Quality

ApiTestCase is a PHPUnit TestCase that will make your life as a Symfony API developer much easier. It extends basic Symfony WebTestCase with some cool features.

Thanks to PHP-Matcher you can, according to its readme, "write expected json responses like a gangster". We definitely agree.

It also uses Alice for easy Doctrine fixtures loading.


  • Clear TDD workflow for API development with Symfony;
  • JSON/XML matching with clear error messages;
  • Fixtures loading with Alice (optional);
  • Easy mocking of Symfony services, which makes it easier to work on SOA-based projects;


Assuming you already have Composer installed globally:

$ composer require --dev lchrusciel/api-test-case

And it's done! ApiTestCase is working with the default configuration.


We provide two base classes for your test cases: JsonApiTestCase and the XmlApiTestCase. Choose one based on the format of the API you want to create.

Json Example

The basic TDD workflow is the following:

  1. Write a test case that sends the request and use assertResponse assertion method to check if response contents are matching your expectations. You need a name for the response file;
  2. Create the file with name that you picked in step 1. and put expected response contents there. It should be put in src/AppBundle/Tests/Responses/Expected/hello_world.json for example.
  3. Make it red.
  4. Make it green.
  5. Refactor.

Let's see a simple example! Write the following test:

namespace AppBundle\Tests\Controller\HelloWorldTest;

use ApiTestCase\JsonApiTestCase;

class HelloWorldTest extends JsonApiTestCase
    public function testGetHelloWorldResponse()
        $this->client->request('GET', '/');

        $response = $this->client->getResponse();

        $this->assertResponse($response, 'hello_world');

Now define the expected response file:

    "message": "Hello ApiTestCase World!"

Run your tests:

$ bin/phpunit

Your test should fail with some errors, you are probably missing the controller and routing, so go ahead and define them! As soon as you implement your Controller and configure appropriate routing, you can run your tests again:

If the response contents will match our expectations, console will present a simple message:

OK (1 tests, 2 assertions)

Otherwise it will present diff of received messages:

"Hello ApiTestCase World" does not match "Hello ApiTestCase World!".
@@ -1,4 +1,3 @@
-    "message": "Hello ApiTestCase World!"
+    "message": "Hello ApiTestCase World"

Firstly, function assertResponse will check the response code (200 is a default response code), then it will check if header of response contains application/json content type. At the end it will check if the response contents matches the expectation. Sometimes you can't predict some values in the response, for example autogenerated date or id from the database. No magic is needed here because PHP-Matcher comes with a helping hand. These are just a few examples of available patterns:

  • @string@
  • @integer@
  • @boolean@
  • @array@

Check for more on PHP-Matcher's documentation.

With these patterns your expected response will look like this:

    "message": "@string@"

With this in place, any string under key message will match the pattern. More complicated expected response could look like this:

        "id": "@integer@",
        "name": "Star-Wars T-shirt",
        "sku": "SWTS",
        "price": 5500,
        "sizes": "@array@",
        "created_at": "@string@.isDateTime()"
        "id": "@integer@",
        "name": "Han Solo Mug",
        "sku": "HSM",
        "price": 500,
        "sizes": "@array@",
        "created_at": "@string@.isDateTime()"

And will match the following list of products:

        'id' => 1,
        'name' => 'Star-Wars T-shirt',
        'sku' => 'SWTS',
        'price' => 5500,
        'sizes' => array('S', 'M', 'L'),
        'created_at' => new \DateTime(),
        'id' => 2,
        'name' => 'Han Solo Mug',
        'sku' => 'HSM',
        'price' => 500,
        'sizes' => array('S', 'L'),
        'created_at' => new \DateTime(),

Testing With Database Fixtures

ApiTestCase is integrated with nelmio/alice. Thanks to this nice library you can easily load your fixtures when you need them. You have to define your fixtures and place them in an appropriate directory. Here is some example how to define your fixtures and use case. For more information how to define your fixtures check Alice's documentation.

In order to use Alice with Doctrine, you should enable two additional bundles:

Symfony 4.0+

// config/bundles.php
return [
    // ...
    Nelmio\Alice\Bridge\Symfony\NelmioAliceBundle::class => ['test' => true],
    Fidry\AliceDataFixtures\Bridge\Symfony\FidryAliceDataFixturesBundle::class => ['test' => true],

Symfony 3

// app/AppKernel.php
class AppKernel extends Kernel
    public function registerBundles()
        // ...

        if ('test' === $this->getEnvironment()) {
            new Nelmio\Alice\Bridge\Symfony\NelmioAliceBundle(),
            new Fidry\AliceDataFixtures\Bridge\Symfony\FidryAliceDataFixturesBundle(),

Now, let's say you have a mapped Doctrine entity called Book in your application:

    class Book 
        private $id;
        private $title;
        private $author;
        // ... 

To load fixtures for the test, you need to define a simple YAML file in src/AppBundle/Tests/DataFixtures/ORM/books.yml:

            title: "Lord of The Rings"
            author: "J. R. R. Tolkien"
            title: "Game of Thrones"
            price: "George R. R. Martin"

Finally, to use these fixtures in a test, just call a proper method:

    public function testBooksIndexAction()
        // This method require subpath to locate specific fixture file in your DataFixtures/ORM directory.
        // There is another method that allows you to load fixtures from directory.

Additional features

You may also add polishsymfonycommunity/symfony-mocker-container library to project and take advantage of mocking external API callse.

First, you have to slightly change your Kernel logic to support SymfonyMockerContainer:

// app/AppKernel.php

use \PSS\SymfonyMockerContainer\DependencyInjection\MockerContainer;

protected function getContainerBaseClass()
    if ('test' === $this->environment) {
        return MockerContainer::class;

    return parent::getContainerBaseClass();

And you are good to test endpoints, which communicate with some external API in a meantime. To check behaviour of our app with different responses from external API we can use SymfonyMockerContainer. This library allows to mock the third party API response, and asserts number of calls. This is extra useful when you work with APIs like Google Maps, Stripe etc. You can also mock response from other apps in your SOA project.

    public function testGetResponseFromMockedService()
        $this->client->getContainer()->mock('app.third_party_api_client', 'ApiTestCase\Test\Service\ThirdPartyApiClient')

From this moment, first getInventory method call will return the response defined in third_party_api_inventory.json file placed in a src/AppBundle/Tests/Responses/Mocked/ folder, or any other location you have defined in phpunit.xml file.

Configuration Reference

To customize your test suite configuration you can add a few more options to phpunit.xml:

    <server name="KERNEL_CLASS" value="Acme\Kernel" />
    <server name="EXPECTED_RESPONSE_DIR" value="/path/to/expected/responses/" />
    <server name="MOCKED_RESPONSE_DIR" value="/path/to/mocked/responses/" />
    <server name="FIXTURES_DIR" value="/path/to/DataFixtures/ORM/" />
    <server name="OPEN_ERROR_IN_BROWSER" value="true/false" />
    <server name="OPEN_BROWSER_COMMAND" value="open %s" />
    <server name="IS_DOCTRINE_ORM_SUPPORTED" value="true/false" />
    <server name="TMP_DIR" value="/tmp/path/to/temporary/folder/" />
    <server name="ESCAPE_JSON" value="true/false" />
  • KERNEL_CLASS allows you to specify exactly which class should be used in order to setup the Kernel.
  • EXPECTED_RESPONSE_DIR and MOCKED_RESPONSE_DIR variables contain paths to folders with expected and mocked responses. EXPECTED_RESPONSE_DIR is used when API result is compared with existing json file. MOCKED_RESPONSE_DIR should contains files with mocked responses from outside API's. Both variable can have same value but we recommend to keep it separated. If these values aren't set, ApiTestCase will try to guess location of responses. It will try to look for the responses in a following folders '../Responses/Expected' and '../Responses/Mocked' relatively located to your controller test class.
  • FIXTURES_DIR variable contains a path to folder with your data fixtures. By default if this variable isn't set it will search for ../DataFixtures/ORM/ relatively located to your test class . ApiTestCase throws RunTimeException if folder doesn't exist or there won't be any files to load.
  • OPEN_ERROR_IN_BROWSER is a flag which turns on displaying error in a browser window. The default value is false.
  • OPEN_BROWSER_COMMAND is a command which will be used to open browser with an exception.
  • IS_DOCTRINE_ORM_SUPPORTED is a flag which turns on doctrine support includes handy data fixtures loader and database purger.
  • TMP_DIR variable contains a path to temporary folder, where the log files will be stored.
  • ESCAPE_JSON is a flag which turns on escaping (unicode characters and slashes) of your JSON output before comparing it to expected data. The default value is false. This flag only exists for backwards compatibility with previous versions of ApiTestCase (when turned on) and will be removed in a future version.

Sample Project

In the test/ directory, you can find sample Symfony project with minimal configuration required to use this library.


In order to run our PHPUnit tests suite, execute following commands:

$ composer install
$ test/app/console doctrine:database:create
$ test/app/console doctrine:schema:create
$ bin/phpunit

Bug Tracking and Suggestions

If you have found a bug or have a great idea for improvement, please open an issue on this repository.


Releases will be numbered with the format major.minor.patch.

And constructed with the following guidelines.

  • Breaking backwards compatibility bumps the major.
  • New additions without breaking backwards compatibility bumps the minor.
  • Bug fixes and misc changes bump the patch.

For more information on SemVer, please visit website.

MIT License

License can be found here.


The library was originally created by:

at Lakion company under repository.

See the list of contributors.