Orkhan's Blog on software development

Testing scheduled commands and jobs in Laravel's console kernel

Your Laravel application’s console kernel probably contains some scheduled tasks. But how do you make sure they are configured correctly and no developer will accidentally remove or modify them?

Take this console kernel as an example:

class Kernel extends ConsoleKernel
{
    protected function schedule(Schedule $schedule): void
    {
        $schedule->command('prune-stale-files')->hourly();
        $schedule->job(VerifyUserSubscriptions::class)->daily();
    }
}

Testing HTTP responses with custom assertions in Laravel

Laravel’s HTTP test assertions are great for testing the response of your application. They provide a lot of methods to assert the response status, headers, content, and more.

But sometimes you have a specific response that you want to test and there’s no built-in method for it, especially when there’s a repeating pattern.

Using Laravel migrations to modify data in tables during deployments

There are many ways to modify data in a table during deployment. Some applications use database seeds, some use console commands and some use custom scripts with raw SQL queries.

But in Laravel, migrations are the easiest and most convenient way to do this. You’ve probably done it several times. You wanted to modify data in a table during deployment and you used a migration to do it.

It gets the job done, doesn’t require any additional setup/script/library, and is version-controlled by default.

Unit testing exceptions in PHP

Let’s imagine we have the following code that runs and conditionally throws an exception:

use Symfony\Component\HttpKernel\Exception\HttpException;

class DeletePostAction
{
    public function execute(Post $post)
    {
        if ($post->is_published) {
            throw new HttpException(403, 'Cannot delete a published post');
        }

        $post->delete();
    }
}

If we want to write test coverage for this class it will require at least 2 test cases:

• Assert that the action deletes the provided post successfully
• Assert that the action throws an exception when the provided post is published

Testing for the existence of controller middleware in Laravel without invoking them

If you are feature-testing your controllers, you’ve probably written test cases like this:

public function testRequiresAuthState(): void
{
    $this->get(route('dashboard'))
        ->assertRedirect(route('login'));
}

Here you intentionally don’t create/assign any user to the session and try to access a route that requires authentication.

Using GitHub Actions to run Vapor deployments

In the previous post, we discussed how to use pre-built Docker images with Laravel Vapor to reduce deployment time. There I also mentioned using GitHub Actions to automate the deployment.

In this post, I want to showcase some examples, including one that uses a private AWS ECR repository as a base image to deploy Vapor applications using GitHub Actions.

Using Imagick extension with PHP 8.3 on Docker

If you use the imagick extension on PHP 8.2 or earlier, it is quite straightforward to install on Docker.

RUN pecl install imagick && \
    docker-php-ext-enable imagick

But currently, and for some time the PECL version of the extension is broken on PHP 8.3.

Using pre-built Docker images with Laravel Vapor to reduce deployment time

Vapor’s custom Docker runtimes are great for customizing environment dependencies, adding PHP extensions, changing configuration, etc.

But doing all of this requires building the deployment image from scratch, on every single deployment. If you are using tools like GitHub Actions to automate the deployment, increased deployment time will eat up your GitHub Actions minutes quickly.

Rendering response from Laravel exception

In your Laravel controller or somewhere in your code you probably have a try/catch like this:

use App\Exceptions\FailedRequestException;

class ApiController
{
    public static sendRequest()
    {
        $api = new SomeApi();
        
        try {
            $api->sendRequest();

            return response()->json([
                'data' => $api->getData(),
            ]);
        } catch(FailedRequestException $e) {
            return response()->json([
                'error' => 'Failed to send API request',
            ]);
        }
    }
}

Using traits to boot and initialize Eloquent models

If you ever used Eloquent events, you are probably aware of special boot() static method in Eloquent models. This method allows you to hook into special events by running given functions.

Here’s an example, let’s say we have a Post model and when we are creating a new post, model needs to generate slug attribute based on name.