Engineering Diary -- Building an API using TDD

February 22nd, 2020

TL;DR - using Test-Driven Development to build an API

(If you like the work I do on OpenCFP, please consider sponsoring me at https://github.com/sponsors/chartjes/)

OpenCFP Central is a companion web application that I run that works with OpenCFP. Right now people can sign up for an account at OpenCFP Central and get an key that can be used to allow OpenCFP to use OpenCFP Central accounts as authentication. This feature was one that was requested for a long time, and I'm happy I can offer it to folks using a more recent versions of OpenCFP.

The next feature I am wanting to build is to add an API to OpenCFP Central that allows talks to be stored there and then can be pulled and submitted to any OpenCFP application that has been updated to include that ability. I'm already using OAuth so I can make the API use that.

OpenCFP Central is currently a Laravel 6 application. I'm using Passport for my OAuth needs. My initial scan of the documentation seems to indicate that is straightforward (but not necessarily easy) to do what I am trying to do.

Models and Resources

This being the first time I've built anything related to an API with Laravel, it looks like the path-of-least-resistance is to use as much of the built-in tools that Laravel gives me. I settled on sending things back and forth as JSON. Looking at the documentation it appears I should be using resources and resource collections. They will in turn become JSON responses via some code behind the scenes.

What makes this appealing to me is that given the lack of time (basically one day a week) I can give my side projects, I can have a lot of the plumbing for these API calls already done.

So, I can use my existing User model and just add a relationship to say that "a User can have one or more Talks"

/**
* @return HasMany
*/
public function talks(): HasMany
{
    return $this->hasMany(Talk::class);
}

Next I have to go back and create my Talk model. But before that I need to create a migration to add it to the database. I decided to keep things simple:

  • an ID
  • a UUID I will use for display purposes
  • the ID of the user the talk belongs to
  • the details of the talk stored as JSON

I am using PostgreSQL as my database and it has a "JSONB" field type.

<?php
declare(strict_types=1);

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

class NewTalksTableAsJsonb extends Migration
{
    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('talks', function (Blueprint $table) {
            $table->increments('id');
            $table->uuid('uuid');
            $table->integer('user_id');
            $table->jsonb('details');
            $table->datetime('created_at');
            $table->datetime('updated_at');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::dropIfExists('talks');
    }
}

The details field needs to contain whatever is the data for an OpenCFP talk that is not configurable by whomever is running it. I believe this to be the following:

  • title of the talk
  • description of the talk
  • and then any other details the speaker wishes to share

So I think a typical JSON payload for an individual talk will look something like this:

{
  "user_id": 1,
  "uuid": "someuuidweusetodisplay",
  "title": "Test Title",
  "description": "Test Description",
  "other": "Things the speaker might want the organizers to know about"
}

With that design in place, time to write my first test. I am going to start with "get one talk for a user. As I always do, I start off with a skeleton of a test with just enough code in it to run and generate a failing response.

<?php
declare(strict_types=1);

use App\Talk;
use App\User;
use Tests\TestCase;

class GetTalkViaApiTest extends TestCase
{
    /**
     * @test
     */
    public function correctlyRetrievesTestAssociatedWithUser(): void
    {
        /**
         * Create a test user
         * Create a talk associated with that user
         * Save the talk
         */

        /**
         * Make an API call to /api/talk/user/{id}
         */

        /**
         * Assert that the JSON response matches what was created
         */
        $this->assertTrue(false);
    }
}

Those three comment blocks represent the three parts of the Arrange Act Assert pattern that I like to use to organize my tests. As always with my tests, I did some prototyping to figure out the best way to do the assertions of the JSON data. Once I figured out the approach I wanted to use, I was ready to start writing the test

So now I need to create a user for the test. I have another test that creates users for testing purposes, so I will use that.

$user = factory(User::class)->create();

Then I create a talk associated with that test and save it to the database

$talkDetails = [
    'title' => 'Test title',
    'description' => 'Test description',
    'other' => 'Test other'
];
$talk = new Talk(); 
$talk->user_id = $talkDetails['user_id'];
$talk->uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'php.net');
$talk->details = json_encode($talkDetails, JSON_THROW_ON_ERROR);
$talk->save();

Next, I have to make a call to my API end point as a user who is authenticated, using a Laravel helper

/**
 * Make an API call to /api/talk/{id}
 */
$response = $this->actingAs($user, 'api')->get('/api/talk/' . $talk->id);

Without adding any more assertions, I run the test to verify that just the assertion I have there is not passing. I am seeing a failure because I have not configured the API route that I need.

According to the documentation, I can set up the route and do the work inside the closure. In this case I want to make sure my query makes sure to return a response only if the user associated with the talk is correct.

This is what my route looks like:

Route::middleware('auth:api')->get('/talk/{id}', function (Request $request, $id) {
    return \App\Talk::find(['id' => $id, 'user_id' => $request->user()->id]);
});

With that done, I now can add in the code I am using for my assertions.

/**
 * Assert that the JSON response matches what was created
 */
$response->assertOk();
$talkViaApi = json_decode($response->content(), true, 512, JSON_THROW_ON_ERROR);
$this->assertEquals($expected['id'], $talkViaApi[0]['id']);
$this->assertEquals($expected['user_id'], $talkViaApi[0]['user_id']);
$this->assertEquals($expected['uuid'], $talkViaApi[0]['uuid']);

/**
 * Because we cannot guarantee the order of things in JSON, we have to look
 * inside the details field a little differently
 */
$talkDetailsFromApi = json_decode($talkViaApi[0]['details'], true, 512, JSON_THROW_ON_ERROR);
foreach ($talkDetails as $field => $value) {
    $this->assertArrayHasKey($field, $talkDetailsFromApi);
    $this->assertEquals($talkDetailsFromApi[$field], $value);
}

This test passes! Next test I need is one where I create talk associated with one user but pass in the wrong user id. It should return a 404 to let me know that it could not find it.

The test initially looks like this:

    public function cannotAccessATalkNotBelongingToADifferentUser(): void
    {
        /**
         * Create a test user
         * Create a talk associated with that user
         * Save the talk
         */
        $user = factory(User::class)->create();
        $this->be($user);

        $talkDetails = [
            'title' => 'Test title',
            'description' => 'Test description',
            'other' => 'Test other'
        ];
        $talk = new Talk();
        $talk->user_id = $user->id - 1;
        $talk->uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'php.net');
        $talk->details = json_encode($talkDetails, JSON_THROW_ON_ERROR);
        $talk->save();

        /**
         * Make an API call to /api/talk/1
         */
        $response = $this->actingAs($user, 'api')->get('/api/talk/' . $talk->id);

        /**
         * Assert that we are getting back a 404
         */
        $response->assertNotFound();
    }

The test fails, telling me I am getting a 200 instead of a 404. Time to back to our route and write some logic to generate the 404. So the code inside the closure now needs to look like this:

Route::middleware('auth:api')->get('/talk/{id}', function (Request $request, $id) {
    $talk = Talk::find($id);

    if ((int)$talk->user_id === (int)$request->user()->id) {
        return $talk;
    }

    abort(404);
});

I run the tests...and it fails, complaining that it can't find things at index 0 in the array that has my results in it. I see that just returning the talk means I get one record instead of an array that contains one record. I fix the test to reflect that change and now I have a completely passing test.

Here is the entire test and I hope this blog post helps you get better at testing the API's you are building.

<?php
declare(strict_types=1);

use App\Talk;
use App\User;
use Ramsey\Uuid\Uuid;
use Tests\TestCase;

class GetTalkViaApiTest extends TestCase
{
    /**
     * @test
     */
    public function correctlyRetrievesTestAssociatedWithUser(): void
    {
        /**
         * Create a test user
         * Create a talk associated with that user
         * Save the talk
         */
        $user = factory(User::class)->create();
        $this->be($user);

        $talkDetails = [
            'title' => 'Test title',
            'description' => 'Test description',
            'other' => 'Test other'
        ];
        $talk = new Talk();
        $talk->user_id = $user->id;
        $talk->uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'php.net');
        $talk->details = json_encode($talkDetails, JSON_THROW_ON_ERROR);
        $talk->save();

        $expected = [
            'id' => $talk->id,
            'user_id' => $user->id,
            'uuid' => $talk->uuid->toString(),
            'details' => $talk->details,
        ];

        /**
         * Make an API call to /api/talk/{id}
         */
        $response = $this->actingAs($user, 'api')->get('/api/talk/' . $talk->id);

        /**
         * Assert that the JSON response matches what was created
         */
        $response->assertOk();
        $talkViaApi = json_decode($response->content(), true, 512, JSON_THROW_ON_ERROR);

        $this->assertEquals($expected['id'], $talkViaApi['id']);
        $this->assertEquals($expected['user_id'], $talkViaApi['user_id']);
        $this->assertEquals($expected['uuid'], $talkViaApi['uuid']);

        /**
         * Because we cannot guarantee the order of things in JSON, we have to look
         * inside the details field a little differently
         */
        $talkDetailsFromApi = json_decode($talkViaApi['details'], true, 512, JSON_THROW_ON_ERROR);
        foreach ($talkDetails as $field => $value) {
            $this->assertArrayHasKey($field, $talkDetailsFromApi);
            $this->assertEquals($talkDetailsFromApi[$field], $value);
        }
    }

    /**
     * @test
     */
    public function cannotAccessATalkNotBelongingToADifferentUser(): void
    {
        /**
         * Create a test user
         * Create a talk associated with that user
         * Save the talk
         */
        $user = factory(User::class)->create();
        $this->be($user);

        $talkDetails = [
            'title' => 'Test title',
            'description' => 'Test description',
            'other' => 'Test other'
        ];
        $talk = new Talk();
        $talk->user_id = $user->id - 1;
        $talk->uuid = Uuid::uuid5(Uuid::NAMESPACE_DNS, 'php.net');
        $talk->details = json_encode($talkDetails, JSON_THROW_ON_ERROR);
        $talk->save();

        /**
         * Make an API call to /api/talk/1
         */
        $response = $this->actingAs($user, 'api')->get('/api/talk/' . $talk->id);

        /**
         * Assert that we are getting back a 404
         */
        $response->assertNotFound();
    }
}

OpenCFP Engineering Diary -- Adding Doctrine

December 2nd, 2019

TL;DR - Adding support to an existing Symfony 3.4 application for Doctrine

(If you like the work I do on OpenCFP, please consider sponsoring me at https://github.com/sponsors/chartjes/)

Part of the medium-term planning for OpenCFP is to refactor the application to stop using Sentinel as the authentication and ACL choice and start using the Symfony Scurity component.

When OpenCFP was first built it was a more standalone solution and I picked Sentinel's predecessor, Sentry. As it got deprecated, we moved to Sentinel and along the way we added in some code to make Eloquent easier to use within the app. When switching to be more Symfony-based, Doctrine is the ORM that needs to be used. So I have a refactoring process that looks like this:

  • Get Doctrine and it's dependencies into the project
  • Refactor everything except our auth stuff to use Doctrine
  • Refactor our authentication and authorization code to use Symfony Security
  • Remove Sentinel and all it's dependencies

I had not used Doctrine in many many years so a lot of things have changed. Given all the trouble I had, I figured I was not alone so it makes sense to document the changes and additions I made.

As with most work I do on OpenCFP, this was a journey of discovering things I needed to know that I did not know.

Packages

Following the directions for Symfony 3.4 I installed my dependencies:

composer require doctrine/orm
composer require doctrine/doctrine-bundle
composer require doctrine/doctrine-cache-bundle

Right now, composer show says I have the following Doctrine-related packages installed now

doctrine/annotations                v1.8.0  
doctrine/cache                      1.9.1   
doctrine/collections                1.6.4   
doctrine/common                     v2.11.0 
doctrine/data-fixtures              1.4.0   
doctrine/dbal                       v2.10.0 
doctrine/doctrine-bundle            1.12.2  
doctrine/doctrine-cache-bundle      1.4.0   
doctrine/doctrine-fixtures-bundle   3.3.0   
doctrine/event-manager              1.1.0   
doctrine/inflector                  1.3.1   
doctrine/instantiator               1.3.0   
doctrine/lexer                      1.2.0   
doctrine/orm                        v2.7.0  
doctrine/persistence                1.2.0   
doctrine/reflection                 v1.0.0  
symfony/doctrine-bridge             v3.4.35 

I may have installed some of these packages manually, but who knows.

Enable Doctrine in the application

The first sign I had no idea what I was doing was when I could not see any of the Doctrine-related commands when I used bin/console. After moaning on Twitter and asking some questions on Stack Overflow, I realized it would not automatically find it. so I added a line to my Kernel.php file so that the bundle would be available.

    public function registerBundles()
    {
        $bundles = [
            new FrameworkBundle(),
            new SensioFrameworkExtraBundle(),
            new MonologBundle(),
            new TwigBundle(),
            new SwiftmailerBundle(),
            new WouterJEloquentBundle(),
            new OneupFlysystemBundle(),
            new DoctrineBundle(),
        ];

        if ($this->getEnvironment() !== Environment::TYPE_PRODUCTION) {
            $bundles[] = new DebugBundle();
        }

        if ($this->getEnvironment() === Environment::TYPE_DEVELOPMENT) {
            $bundles[] = new WebServerBundle();
            $bundles[] = new WebProfilerBundle();
        }

        return $bundles;
    }

Making repositories available as a service

I had to update my `resources/config/services/services.yml' file with the following new section to allow the app to find and inject all the repository files I was going to create:

 OpenCFP\Domain\Repository\:
    public: true
    resource: '%kernel.project_dir%/src/Domain/Repository/*'

Configuration Files

To make Doctrine see the database connections, I had to modify the following files:

resources/config/config_development.yml
resources/config/config_testing.yml
resources/config/config_production.yml

adding in the following details (determined through trial-and-error and online searches for help)

doctrine:
  dbal:
    url: mysql://root:@127.0.0.1:3306/cfp
    default_table_options:
      charset: utm8mb4
      collate: utg8mb4_unicode_ci
  orm:
    auto_mapping: true
    auto_generate_proxy_classes: true
    mappings:
      OpenCFP\Domain\Entity:
        type: annotation
        dir: "%kernel.root_dir%/../src/Domain/Entity"
        prefix: OpenCFP\Domain\Entity

Early on I had my integration test suite failing to even run because it was complaining it could not find the new repository I had created:

<?php

declare(strict_types=1);

/**
 * Copyright (c) 2013-2019 OpenCFP
 *
 * For the full copyright and license information, please view
 * the LICENSE file that was distributed with this source code.
 *
 * @see https://github.com/opencfp/opencfp
 */

namespace OpenCFP\Domain\Repository;

use Doctrine\ORM\EntityManagerInterface;
use Doctrine\ORM\EntityRepository;
use OpenCFP\Domain\Entity\Airport;

final class AirportRepository
{
    /**
     * @var EntityRepository
     */
    private $repository;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->repository = $entityManager->getRepository(Airport::class);
    }

    public function withCode(string $code): ?Airport
    {
        $airport = $this->repository->findOneByCode($code);

        if ($airport !== null) {
            return $airport;
        }

        return null;
    }
}

Here's the entity I created to go with it

<?php

declare(strict_types=1);

/**
 * Copyright (c) 2013-2019 OpenCFP
 *
 * For the full copyright and license information, please view
 * the LICENSE file that was distributed with this source code.
 *
 * @see https://github.com/opencfp/opencfp
 */

namespace OpenCFP\Domain\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity
 * @ORM\Table(name="airports")
 */
final class Airport
{
    /**
     * @ORM\Column(type="string", length=3)
     * @ORM\Id
     */
    private $code;

    /**
     * @ORM\Column(type="string", length=255)
     */
    private $name;

    /**
     * @ORM\Column(type="string", length=255)
     */
    private $country;

    /**
     * @return mixed
     */
    public function getCode()
    {
        return $this->code;
    }

    /**
     * @return mixed
     */
    public function getName()
    {
        return $this->name;
    }

    /**
     * @return mixed
     */
    public function getCountry()
    {
        return $this->country;
    }
}

The issue turned out to be I needed to set auto_generate_proxy_classes to be true. The error messages from the application itself were not helpful (complaining it could not inject the EntityManagerInterface my code was using). Anyway, once I figured that out my integration test suite passed. Now I could go and modify my code to use the new repository instead of the Eloquent model.

Here's a summary of the steps I took to update the action that uses airport details

  • removed references to the AirportInformationDatabase object that was used to access the list of airports and codes
  • added in the use of the new AirportRepository object
  • updated the constructor for the action to accept AirportRepository as a parameter via the magic of autowiring dependencies
  • updated the code to use the new repository (and fix a code smell involving an exception being caught but never reacted to)

So now my tests pass and I have a way to add more Doctrine entities and repositories going forward.

Mocking a function with different return values in Python

May 15th, 2019

For the first half of 2019 I was borrowed by the Performance Team at Mozilla and asked to help them implement a way to measure the performance of various browsers on Android platforms. This has involved me getting familiar with several tools and environments that I had not touched before:

  • Mozilla's tooling for use with mozilla-central
  • Rooting Android devices for testing purposes
  • Android Studio and it's device emulation tools
  • Executing and parsing shell commands

Of course, I am using pytest as well to make sure that I had thought about testing scenarios and giving whomever supports this code once I am back at my previous role a chance to figure out what is going on.

One of the testing scenarios I came up with was handing the fact that I had designed the code to have a fallback mode in case the shell command I was using did not work on that particular device. Some code reviews from other developers revealed some differences in how the top command works on different phones.

So, drawing on my own experiences with using test doubles in PHP, I asked myself "how can I create a mock that has different return values?". In pytest this functionality is called side_effect.

So, here is some of the code in question that I needed to test:

try:
    cpuinfo = raptor.device.shell_output("top -O %CPU -n 1").split("\n")
    raptor.device._verbose = verbose
    for line in cpuinfo:
    data = line.split()
            if data[-1] == app_name:
                cpu_usage = data[3]
except Exception:
    cpuinfo = raptor.device.shell_output("dumpsys cpuinfo | grep %s" % app_name).split("\n")
    for line in cpuinfo:
        data = line.split()
        cpu_usage = data[0].strip('%')

I wrapped the first call in a try-catch construct because an exception is thrown if anything is up with that top call. If that call doesn't work, I then want to use that dumpsys call.

In the test itself, I would need the shell_output call to first throw an exception (as expected for the scenario) and then return some output that I can then parse and use.

In the PHP world, most test doubling tools allow you to create a mock and have it return different values on consecutive calls. Pytest is no different, but it took me a while to figure out the correct search terms to find the functionality I wanted.

So, here is how I did it:

def test_usage_with_fallback():
    with mock.patch('mozdevice.adb.ADBDevice') as device:
        with mock.patch('raptor.raptor.RaptorControlServer') as control_server:
            '''
            First we have to return an error for 'top'
            Then we return what we would get for 'dumpsys'
            '''
            device.shell_output.side_effect = [
                OSError('top failed, move on'),
                ' 34% 14781/org.mozilla.geckoview_example: 26% user + 7.5% kernel'
            ]
            device._verbose = True

            # Create a control server
            control_server.cpu_test = True
            control_server.test_name = 'cpuunittest'
            control_server.device = device
            control_server.app_name = 'org.mozilla.geckoview_example'
            raptor = Raptor('geckoview', 'org.mozilla.geckoview_example', cpu_test=True)
            raptor.device = device
            raptor.config['cpu_test'] = True
            raptor.control_server = control_server

            # Verify the response contains our expected CPU % of 34
            cpuinfo_data = {
                u'type': u'cpu',
                u'test': u'usage_with_fallback',
                u'unit': u'%',
                u'values': {
                    u'browser_cpu_usage': '34'
                }
            }
            cpu.generate_android_cpu_profile(
                raptor,
                "usage_with_fallback")
            control_server.submit_supporting_data.assert_called_once_with(cpuinfo_data)

Let me break down what I did (as always, I am open to suggestions on better ways to write this test).

The first double is for a class that communicates with the Android device. Then the next double I needed was for the "control server", which is what is used to control the browser and execute tests.

My first "side effect" is to generate an error so it triggers the first condition of the scenario that 'top should not work'. The second "side effect" is the response I am expecting to get from the shell command in my fallback area of the code.

Then I continue with the "arrange" part of the Arrange-Act-Assert testing pattern I like to use -- I configure my "control server" to be the way I want it.

I finish up with creating what I expect the data that is to be submitted to our internal systems looks like.

I execute the code I am testing (the "act" part) and then use a spy to make sure the control server would have submitted the data I was expecting to have been generated.

The ability to have a method return different values is powerful in the context of writing tests for code that has conditional behaviour. I hope you find this example useful!