Posted on Sep 5 In our journey as developers, we often find ourselves creating applications that need to export reports or pages to PDF format. For a long time, we used various libraries for this task, such as mPDF, FPDF, wkHtmlToPdf, among others. However, today, in my humble opinion, we have one of the best packages for PDF generation on the market, which is Browsershot. It's straightforward to configure and generate PDF files.But, here's the issue some devs face: How can I write tests for a Class that uses Browsershot? Let's dive a bit deeper.Imagine we have a class called GeneratePdf that takes a file name, a URL to render, and maybe the paper size as parameters. This class will save our PDF to AWS S3.⚠️ The examples here are written in a Laravel application and using Pest for automated tests.Fantastic! Our action will save the PDF and return the path so that we can use it in an email, save it in a database, and so on. The only responsibility of this class is to generate the PDF and return the path.But now, how do we test this little guy?Okay, in this phase, let's write a simple test to see if everything works as expected.However, you might notice that our test takes a while to execute. But why?Our test took a while because Browsershot made a request to google.com to fetch its content and create the PDF for you.Alright, it's just one test, what's the harm in that? Let's think:So, how can we write our test more efficiently?with MOCKERY ✨✨✨To simulate the behavior of a class, we can use the Mockery library, which is already available in PHPUnit and Pest.This library provides an interface where we can mimic or spy on our class's behavior to make assertions on the methods that were called.But there's a problem (there always is), a static call...Static methods are great, especially for helper classes, such as a method that checks whether a CPF (Brazilian social security number) is valid or not. In such cases, since we won't have access to $this, we can make these methods static without any issues.However, this comes at a cost...Writing unit tests for static methods is straightforward. We call the method and make the necessary assertions, simple as that. But what if I need to mock a class that calls a static method and then calls its non-static methods?According to the Mockery documentation, it doesn't support mocking public static methods. To work around this, there's a kind of hack to bypass this behavior, which involves creating an alias. (You can read more about it here).Alright, but what does this do? When we use alias:, we're telling Composer:"Hey, when I need Browsershot, bring this one here to me, not the original class."The catch is that even Mockery doesn't recommend using alias: or overload:. This can lead to class name collision errors and should be run in separate PHP processes to avoid this.So, my friend, how do I write this test?In fact, let's change the approach on how we use Browsershot :)By analyzing the Browsershot::url method, we can discover what it does, and it's extremely simple.Great, to avoid using alias: or overload:, we can simply inject Browsershot into our class. Now, it looks like this:This way, mocking becomes much lighter and efficient:If you're using Laravel, you can use the $this->mock method, which interacts directly with the framework's container.Our test now looks like this:By doing this, we make our class loosely coupled, allowing us to perform a wide range of tests without much hassle, and we get to use a powerful pattern, which is dependency injection.Until next time, folks. 😗 🧀Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Russell Jones - Jun 2 Kevin Toshihiro Uehara - Jul 1 Bartłomiej Rasztabiga - Jun 11 Chris Cook - Jun 28 Once suspended, devlopez will not be able to comment or publish posts until their suspension is removed. Once unsuspended, devlopez will be able to comment and publish posts again. Once unpublished, all posts by devlopez will become hidden and only accessible to themselves. If devlopez is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Matheus Lopes Santos. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag devlopez: devlopez consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging devlopez will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.