GuzzleHttp VCR

Project

A few days ago I pushed out a very small library to help with testing APIs using Guzzle: dshafik/guzzlehttp-vcr.

This is a simple middleware that records a request’s response the first time it’s made in a test, and then replays it in response to requests in subsequent runs.

It does this by returning a Guzzle \GuzzleHttp\HandlerStack with either the \Dshafik\GuzzleHttp\VCRHandler middleware, or the GuzzleHttp\Handler\MockHandler added. The first will record the responses to JSON files, while the latter will be pre-loaded with those responses and will return them when requests are made.

It’s important to understand that the responses are returned in order regardless of whether it is the same request being made.

The purpose of this library is to just make it easier to create and update your tests for API clients.

Usage is simple, just call Dshafik\GuzzleHttp\VCRHandler::turnOn() passing in the storage location before running the test, and pass in the handler as a guzzle client option:

You can pass in the handler when instantiating the \GuzzleHttp\Client, or when making the individual requests — if you use the same instance for the individual requests it will re-use the same JSON file for storage, otherwise if you pass in unique instances (with unique storage files) it will create individual ones. I recommend passing in the handler to the constructor, but ensuring that you use a new instance (of the middleware, and the client) for each test.

Hopefully folks find this useful, do let me know if you do. If you have issues, please report them and pull requests are welcome!

I’ll be releasing a new Akamai library which uses dshafik/guzzlehttp-vcr next week (probably) so look out for that if you want to see it’s use in a real project.

Return Values

Standard

Outdated Content

This post is over 7 years old and is probably out of date.

In #phpc we recently had a discussion about function return values; specifically from database queries.

I’m going to go on a (admittedly, rather sturdy looking) limb and say this applies to pretty much any function that returns from a data resource, not just a database .

My preference, is to return false only for error conditions, or when a function is supposed to only return one result (i.e. when selecting on a primary key) and fails to find any result.

However, it’s very rare that I care about whether I hit an error condition or just got no result when it comes to display — more to the point, my user doesn’t care.

There is a simply solution though, an empty array, also evaluates as false.

[php]
function getData()
{
    if (error()) {
        return false;
    } elseif (noData()) {
        return array();
    } else {
        return myData();
    }
}

if (!$data = getData()) {
    foreach ($data as $row) {
         // Show data
    }
} else {
    echo “No data found.”;
}

// or

$data = getData();

if ($data === false) {
    myLog(“Something Bad Happened!”);
}

if (!$data) {
   echo “No data found.”;
} else {
   // iterate
}
[/php] 

This gives the best of both worlds IMO — the ability to distinguish error conditions or not depending on if you need to in the given context.

– Davey

P.S.

This might be the start of a series of thoughts on common API best practices