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;
}
}
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);
});
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(...)
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);
});
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);
}
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;
}
}
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);
});
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);
});
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)