DEV Community: Ivanka Todorova

Laravel 10+: Unit testing custom validation rules

Ivanka Todorova — Fri, 19 Apr 2024 10:21:28 +0000

This post covers one of the ways you can test custom validation rules in Laravel. It assumes you're running a Laravel version no older than 10.x.
I prefer this way of testing as it's the cleanest and more concise of others you can find online.

I will be using the custom rule provided in the official documentation:

// ./app/Rules/Uppercase.php
<?php

namespace App\Rules;

use Closure;
use Illuminate\Contracts\Validation\ValidationRule;

class Uppercase implements ValidationRule
{
    /**
     * Run the validation rule.
     */
    public function validate(string $attribute, mixed $value, Closure $fail): void
    {
        if (strtoupper($value) !== $value) {
            $fail('The :attribute must be uppercase.');
        }
    }
}

This is a very simple and straightforward rule that tests a field to see if it contains only uppecase letters. It doesn't take into account any other data in the request (or elsewhere). If you've worked with older Laravel versions, you will notice that the old passes and message have been replaced by a single validate() method's that doesn't return anything (but voidness).

A test class for the code above looks like this:

// ./tests/Unit/Rules/Uppercase.php

<?php

namespace Tests\Unit\Rules;

use Tests\TestCase;
use App\Rules\Uppercase;

class UppercaseTest extends TestCase {

    const VALID_STRINGS = [
        'I1M UP3RC4SE',
        'I AM UPPERCASE',
        '0TH3R_UPP3RC4S3'
    ];

    const INVALID_STRINGS = [
        'I MiGhT BE UPP3R',
        'bUt I am Not'
    ];

    /**
    * @test
    */
    public function validation_passes_for_valid_strings() {
        $rulew = new Uppercase();

        foreach(self::VALID_STRINGS as $string) {
            $rule->validate('name', $string, function () use ($string) {
                $this->assertTrue(
                    false,
                    sprintf("String is not uppercase only: %s", $string)
                );
            });
        }

        $this->asserTrue(true);
    }

    /**
    * @test
    */
    public function validation_fails_for_invalid_strings() {
        $rulew = new Uppercase();
        $timesFailed = 0;

        foreach(self::INVALID_STRINGS as $string) {
            $rule->validate('name', $string, function () use ($string, &$timesFailed) {
                $timesFailed++;
            });
        }

        $this->assertEquals(
            count(self::INVALID_STRINGS),
            $timesFailed,
            'All strings must fail validation'
        );
    } 
}

The test validation_passes_for_valid_strings() creates an instance of our custom rule and then iterates all strings inside the VALID_STRINGS constant. On each iteration we call the Uppercase::validate method and (here comes the cool part) as a closure we're telling our rule assert an always failing comparison and log our failing $string.

Additionally, we are asserting a seemingly redundant check true===true to avoid getting this message in phpunit:

! validation passes for valid strings → This test did not perform any assertions 0.50s

Tests: 1 risky (0 assertions)

The other test validation_fails_for_invalid_strings() counts the number of fails and asserts the number is equal to the total strings inside INVALID_STRINGS.

And that's it!

Handling class names derived from variables with Blade and TailwindCSS

Ivanka Todorova — Sun, 01 May 2022 11:34:30 +0000

First, you need to have TailwindCSS already setup with Laravel. To do so, you can follow the official documentation at TailwindCSS.

Since TailwindCSS requires classes to be present in whatever file you have specified inside your content array in tailwindcss.config.js, during your development you might experience missing styles due to the usage of variables inside your *.blade.php files (for example).

Consider the following case, you have few buttons that look exactly the same except for their background color:

<!-- button for default operations: eg. login -->
<button type="button" class="bg-blue-700 hover:bg-blue-800 focus:ring-blue-300 focus:ring-4 text-white font-medium rounded-lg text-sm px-5 py-2.5 mr-2 mb-2">Default</button>

<!-- button for potentially dangerous operations: eg. disabling 2FA -->
<button type="button" class="bg-orange-700 hover:bg-orange-800 focus:orange-orange-300 focus:ring-4 text-white font-medium rounded-lg text-sm px-5 py-2.5 mr-2 mb-2">Warning</button>

<!-- button for dangerous operations: eg. deleting -->
<button type="button" class="bg-red-700 hover:bg-red-800 focus:ring-red-300 focus:ring-4 text-white font-medium rounded-lg text-sm px-5 py-2.5 mr-2 mb-2">Danger</button>

What changes in each button is the css utility classes applied for background color. Now since the markup is the same and the styling for text also matches each button, let's create an Anonymous Blade Component button:

// ./resources/views/components/button.blade.php
@props(['color' => 'blue'])

<button type="button" class="bg-{$color}-700 hover:bg-{$color}-800 focus:ring-{$color}-300 focus:ring-4 text-white font-medium rounded-lg text-sm px-5 py-2.5 mr-2 mb-2">
    {{$slot}}
</button>

And use it in our view as follows:

<x-button color="blue"> Default </x-button>

However, since the class names use php variable (bg-{$color}-700), TailwindCSS isn't able to extract them (don't forget to run npm run watch / npm run dev) and your buttons won't look as expected (almost invisible, white text on white background yikes).

To solve this, let's create several new components, representing the state of our button and one base component containing the common styles between them, in a new folder at views/components/button:

// ./resources/views/components/button/base.blade.php
<button type="button" {{$attributes->merge([class="text-white font-medium rounded-lg text-sm px-5 py-2.5 mr-2 mb-2"])}}>
    {{$slot}}
</button>

Now let's create the default "state" of our button:

// ./resources/views/components/button/default.blade.php
<x-button.base class="bg-blue-700 hover:bg-blue-800">
{{$slot}}
</x-button.base>

And we can use the Default button in our views as follows:

<x-button.default>Default</x-button>

If you run npm run dev, you will see that the button now has a background color, you can do the same thing for all button states that you have and tailwindcss will be able to extract those classes with no problem.

![Preview of button](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/c8jnx41czz31z9s14gd7.png)

Laravel Cashier: Multiple Stripe accounts based on Billable's property

Ivanka Todorova — Fri, 06 Aug 2021 12:59:42 +0000

If your application bills customers internationally, sometimes you need multiple Stripe Accounts for all your companies.

Laravel Cashier doesn't support charging customers from different Stripe accounts out-of-the box, but achieving this is pretty easy.

I will not go through the whole setup of Cashier for a single Stripe account, because Laravel's documentation is fantastic: thorough and easy to follow: Laravel Cashier. The account you setup here, will be the fallback/default account if the Billable model (usually App\Models\User) can't be used to resolve the correct Stripe account.

After you're done setting Cashier up, create a new trait called MyBillable. I tend to keep my traits in a folder inside where they are used. Meaning MyBillable trait will go inside traits folder located in app/models.

After creating the App\Models\Traits\MyBillable, add this as content:

<?php
namespace App\Models\Traits;


use Laravel\Cashier\Billable;
use Laravel\Cashier\Cashier;

trait MyBillable
{
    use Billable;


    /**
     *  Override stripe configuration based on User's country preference
     *
     * @param  array  $options
     * @return \Stripe\StripeClient
     */
    public function stripe(array $options = [])
    {

        return Cashier::stripe($options);
    }
}

The code above does nothing for now, but we will expand the App\Models\Traits\MyBillable::stripe() method later.

If you have followed the setup instructions from the official documentation, your billable model (usually App\Models\User) has the Laravel\Cashier\Cashier\Billable trait used. Go ahead and replace it with our new one MyBillable (which also leverages all provided functionality in Cashier by use-ing it inside).

Verify your application is working properly, as if we haven't made any changes after the Cashier setup.

Inside your App\Models\Traits\MyBillable::stripe() method you can use $this to access your User model and write your own logic to determine which of your Stripe accounts is correct for that customer.

In my case, my users belongsTo countries and each country has country code which I use to get previously set .env variables with my stripe secret, stripe key and currency for Cashier.

To do so, create a new config file billing.php inside config/ folder:

return [
    'stripe' => [
        'bg' => [
            'key' => env('BG_STRIPE_KEY'),
            'secret' => env('BG_STRIPE_SECRET'),
            'currency' => env('BG_CASHIER_CURRENCY'),
        ],
        'pl' => [
            'key' => env('PL_STRIPE_KEY'),
            'secret' => env('PL_STRIPE_SECRET'),
            'currency' => env('PL_CASHIER_CURRENCY'),
        ]
    ],
];

Modify your .env key and add:

# Bulgaria Cashier Setup
BG_STRIPE_KEY=
BG_STRIPE_SECRET=
BG_CASHIER_CURRENCY=

# Poland Cashier Setup
PL_STRIPE_KEY=
PL_STRIPE_SECRET=
PL_CASHIER_CURRENCY=

Lastly, update the method in your MyBillable trait to:

public function stripe(array $options = [])
{
    if (!is_null($this->country)) {
        // Get country specific cashier key
        $config = config('billing.stripe');
        if (array_key_exists($this->country->code, $config)) {
            // Update cashier's config
            config(['cashier.key' => $config[$this->country->code]['key']]);
            config(['cashier.secret' => $config[$this->country->code]['secret']]);
            config(['cashier.currency' => $config[$this->country->code]['currency']]);
        }
    }
    // use default config
    return Cashier::stripe($options);
}

The method above is called every time Cashier needs an instance of StripeClient (provided by Cashier's dependency: stripe-php), so by altering Cashier's config we are getting an instance of the StripeClient for the specified Stripe account.

That's it! You are now creating customers in the appropriate Stripe account based on your logic.

What's next? Cashier also provides webhooks to tell your application about changes made outside of it (related to your customers, subscriptions, payments, etc).

~~In my next post I will explain how to create different endpoints in your application to handle the calls issued by your multiple Stripe accounts~~

Check out the comments below to see a way of handling webhooks.