Fixture for requests returning files

[derheyne]

Hey Sam! Love your package! It really came in clutch for version 2 of our app and the upgrade to Saloon v2 is already underway.

A small thing we've found during testing APIs is the inability to save fixtures of requests returning files. Instead, it throws an error Malformed UTF-8 characters, possibly incorrectly encoded. This most likely happens because the string representation of the resource contains some weird, non-UTF8, characters.

I got it working by encoding the request body with base64 when mb_check_encoding returns false:

use Sammyjo20\Saloon\Data\FixtureData as FixtureDataBase;

class FixtureData extends FixtureDataBase
{
    public static function fromFile(string $contents): static
    {
        $fileData = json_decode($contents, true, 512, JSON_THROW_ON_ERROR);

        if (isset($fileData['encoder'])) {
            $fileData['data'] = base64_decode($fileData['data']);
        }

        return new static(
            statusCode: $fileData['statusCode'],
            headers: $fileData['headers'],
            data: $fileData['data'],
        );
    }

    public function jsonSerialize(): array
    {
        $responseData = parent::jsonSerialize();

        if (! mb_check_encoding($responseData['data'])) {
            $responseData['data'] = base64_encode($responseData['data']);
            $responseData['encoder'] = 'base64';
        }

        return $responseData;
    }
}

Unfortunately, it's quite complicated to change since FixtureData in v1 is deeply nested in some classes that can't easily be overwritten.

• Writing: MockResponse::fixture() → Fixture::getMockResponse() → FixtureData
• Reading: SaloonRequest::getRequestManager() → RequestManager::send() → RequestManager::createGuzzleClient() → FixtureRecorderMiddleware::storeResponse()

From what I've tried it's basically impossible to get the FixtureRecorderMiddleware overwritten becuase it's always pushed at the end of Guzzle's handler stack and overwriting the entire trace for reading is nearly impossible since RequestManager::createGuzzleClient() is private and one had to recreate much of the code.

It would be great when there'd be an easier way to do this in v1 or even in v2 where FixtureData has changed to RecordedResponse.

I would love to hear your opinion on this.

[Sammyjo20]

Hey @derheyne

Many thanks for your message - and I love hearing feedback about how Saloon is useful for projects like yours!

Great find by the way, and I think your suggested idea of base64_encoding and decoding the body before serializing the recorded response/fixture would be a sensible option. I assume that would mean it doesn't matter if there are any weird UTF-8 characters, it would be stored in a nice, standardised way.

I would be very willing to help out with this, do you have any suggestions on how I could replicate it? Does the API your returning just return the raw file contents as plain text or within JSON? I could quite easily build an endpoint in my https://tests.saloon.dev app which just returns a PDF file or something like that to test file downloads.

Let me know your thoughts and how I can replicate it. I will likely fix both v1 and v2 as I understand people may still be on version one.

[derheyne]

Amazing! Looking forward to it!

[Sammyjo20]

Hey, I've started a branch for this https://github.com/Sammyjo20/Saloon/tree/fix/v1-encoded-files-in-fixtures

I managed to replicate the issue by using Storage::download() on Saloon's test API, and I've fixed it by using the base64 encode which is good, so thank you for helping me with that, as well as specifying the encoder. That's required for keeping this backwards compatible.

I just need to work out how to base64_encode the array and know to decode it properly too.

[derheyne]

Hey @Sammyjo20, sorry for my late reply.

Good job with the code so far! The direct comparison of the two files in your tests blew my mind. It didn't even cross mine when writing the tests for my implementation :D

May I suggest to just leave arrays and other simple types as they are and not encode them with Base64 for better readability when looking at fixtures directly? In my initial example I used mb_check_encoding($data, 'utf-8') to check if the response data contained invalid or unusual characters and only then encoded it since it doesn't include any legible information anyway. According to the docs json_encode expects a valid UTF-8 encoded string (see parameter value documentation) so that function should do the trick.

[Sammyjo20]

Ah okay, so what you are saying is - only encode if mb_check_ecoding returns false? Because json_encode will basically handle all of that for you anyway?

[derheyne]

Exactly. Only encode data with base64 when json_encode would fail to do so.