DEV Community

Cover image for Mockando a biblioteca BrowserShot em seus testes
Matheus Lopes Santos
Matheus Lopes Santos

Posted on

Mockando a biblioteca BrowserShot em seus testes

Em nossa carreira como dev acabamos por fazer várias aplicações que necessitam exportar algum relatório, ou página, em PDF. Por muito tempo, nós usamos várias bibliotecas para isso, como a mPDF, FPDF, wkHtmlToPdf dentre outras. Hoje temos, na minha humilde opinião, um dos melhores packages para geração de PDF no mercado, que é o Browsershot. Muito simples de configurar e gerar arquivos PDF pra gente.

Porém, vejo alguns devs com o seguinte problema: Como posso escrever testes para uma classe que vai fazer uso do Browsershot? Vamos mergulhar um pouco mais.

Vamos imaginar que temos uma classe chamada GeneratePdf e que aceitará um nome para o arquivo, uma URL para ser renderizada e, talvez, o tamanho do papel. Essa classe irá salvar o nosso PDF na AWS S3.

⚠️ Os exemplos aqui escritos foram feitos em uma aplicação Laravel e utilizando o pest para testes automatizados

<?php

declare(strict_types=1);

namespace App\Actions;

use Illuminate\Support\Facades\Storage;
use Spatie\Browsershot\Browsershot;

class GeneratePdf
{
    public function handle(
        string $fileName,
        string $url,
        string $paperSize = 'A4'
    ): string | false {
        $path    = '/exports/pdf/' . $fileName;
        $content = Browsershot::url($url)
            ->format($paperSize)
            ->noSandbox()
            ->pdf();

        if (!Storage::disk('s3')->put($path, $content)) {
            return false;
        }

        return $path;
    }
}
Enter fullscreen mode Exit fullscreen mode

Maravilha, a nossa action vai salvar o PDF e retornar o caminho para que possamos utilizar ele em um e-mail, salvar em um banco de dados, etc. A única responsabilidade dessa classe é gerar o PDF e retornar o caminho.

Mas, e agora, como faço para testar esse carinha?

Escrevendo meus testes

Beleza, nessa fase escrevemos um teste simples para ver se tudo vai funcionar como esperamos.

it('should generate a pdf', function () {
    Storage::fake('s3');

    $pdf = (new GeneratePdf())->handle(
        fileName: 'my-file-name.pdf',
        url: 'https://www.google.com'
    );

    Storage::disk('s3')
        ->assertExists($pdf);
});
Enter fullscreen mode Exit fullscreen mode

Contudo, podemos notar que o nosso teste vai demorar um pouco. Mas, por quê?

Nosso teste demorou a ser executado por que o Browsershot fez uma requisição ao google.com para pegar seu conteúdo e montar o pdf pra você.

Ok, ok. É um teste apenas, que mal há nisso? Vamos pensar:

  • E se houver mais de uma classe que faz uso do Browsershot?
  • E se você estiver sem internet? - O teste falha;
  • E se você estiver utilizando um serviço de pipeline pago? O teste vai demorar e você vai pagar a mais por isso;

Então Matheusão, como faço para escrever meu teste de uma forma mais eficiente?

Com MOCKERY ✨✨✨

Mockery

Para que possamos simular o comportamento de uma classe, podemos usar a biblioteca Mockery, que já vem disponível no PHPUnit e no Pest.

Essa lib provê uma interface onde eu posso simular o comportamento da minha classe, ou expiá-la, para que possamos fazer o assert dos métodos que foram chamados.

Mas existe um problema (sempre ele), uma chamada estática...

BrowserShot::url(...)
Enter fullscreen mode Exit fullscreen mode

O problema dos métodos estáticos.

Métodos estáticos são legais, principalmente para classes de helpers, como por exemplo, um método que checa se um CPF é válido ou não.

Nesses casos, como sei que não terei acesso ao $this, posso desenhar esse método para ser estático, sem problema algum.

Porém, isso tem um custo...

Fazer testes unitários para métodos mágicos é muito simples. Chamo o meu método e faço as asserções que preciso, simples assim. Mas e quando eu preciso mockar uma classe que está chamando um método estático e, logo após, chama os métodos não estáticos dela?

Segundo a documentação do mockery, ele não suporta o mocking de métodos públicos estáticos. Para fazer isso, existe uma espécie de hack para burlar esse comportamento, que é criando um alias. (Você pode ler mais aqui)

it('should generate a pdf', function () {
    Storage::fake('s3');

    mock('alias:' . Browsershot::class)
        ->shouldReceive('url->format->noSandbox->pdf');

    $pdf = (new GeneratePdf())->handle(
        fileName: 'my-file-name.pdf',
        url: 'https://www.google.com'
    );

    Storage::disk('s3')
        ->assertExists($pdf);
});
Enter fullscreen mode Exit fullscreen mode

Show, mas, o que isso faz? Quando usamos o alias:, nós dizemos ao composer:

Olha, quando eu precisar do Browsershot, traz esse carinha aqui pra mim, não a classe original.

O detalhe é que nem a própria mockery recomenda que façamos uso do alias: ou do overload:. Isso pode causar erros de colisão de nomes de classes e devem ser executados em processos PHP separados para evitar isso.

Pô amigo, como vou escrever esse teste?

Na verdade, vamos mudar a abordagem de como usamos o Browsershot :)

Análise de dependência e Dependency Injection

Ao analisar o método Browsershot::url, podemos descobrir o que ele faz, e é extremamente simples.

public static function url(string $url): static
{
    return (new static())->setUrl($url);
}
Enter fullscreen mode Exit fullscreen mode

Massa, então para evitar o uso de alias: ou overload:, podemos simplesmente injetar o browsershot em nossa classe. Agora ela fica assim:

<?php

declare(strict_types=1);

namespace App\Actions;

use Illuminate\Support\Facades\Storage;
use Spatie\Browsershot\Browsershot;

class GeneratePdf
{
    public function __construct(
        private Browsershot $browsershot
    ) {
    }

    public function handle(
        string $fileName,
        string $url,
        string $paperSize = 'A4'
    ): string | false {
        $path    = '/exports/pdf/' . $fileName;
        $content = $this->browsershot->setUrl($url)
            ->format($paperSize)
            ->noSandbox()
            ->pdf();

        if (!Storage::disk('s3')->put($path, $content)) {
            return false;
        }

        return $path;
    }
}

Enter fullscreen mode Exit fullscreen mode

Dessa forma, o mock fica muito mais leve e eficiente:

it('should generate a pdf', function () {
    Storage::fake('s3');

    $mock = mock(Browsershot::class);
    $mock->shouldReceive('setUrl->format->noSandbox->save');

    $pdf = (new GeneratePdf($mock))->handle(
        fileName: 'my-file-name.pdf',
        url: 'https://www.google.com'
    );

    Storage::disk('s3')
        ->assertExists($pdf);
});
Enter fullscreen mode Exit fullscreen mode

Se você estiver utilizando o Laravel, pode usar o método $this->mock que vai interagir diretamente com o container do framework.

Nosso teste fica assim:

it('should generate a pdf', function () {
    Storage::fake('s3');
    Storage::put('pdf/my-file-name.pdf', 'my-fake-file-content');

    $this->mock(Browsershot::class)
        ->shouldReceive('setUrl->format->noSandbox->save');

    $pdf = app(GeneratePdf::class)->handle(
        fileName: 'my-file-name.pdf',
        url: 'https://www.google.com'
    );

    Storage::disk('s3')
        ->assertExists($pdf);
});
Enter fullscreen mode Exit fullscreen mode

Dessa forma, deixamos a nossa classe fracamente acoplada, com uma ampla gama de testes que podemos fazer sem penar muito e, de quebra, ainda podemos fazer uso de um pattern poderoso que é a injeção de dependência.

Até a próxima, pessoal. 😗 🧀

Top comments (0)