How to test package config modification?

Hi, I'm experiencing package development and want to test that my config variables actually applies the modification they are designed to.

The same way Telescope does, I'd like to provide a way to modify the package dashboard domain & path .

I wrote this configs and test:

// My package config file:
return array [
    'domain' => env('MY_PACKAGE_DOMAIN'),
    'path' => env('MY_PACKAGE_PATH', 'dashboard'),
];

// My package routes file:
Route::group([
    'domain' => config('my-package.domain'),
    'namespace' => 'RomainMazB\MyPackage\Http\Controllers',
    'prefix' => config('my-package.path')
], function () {
    Route::get('/', 'HomeController@index')->name('dashboard');
});

test("Dashboard domain can be modified", function () {
    config()->set('my-package.domain', 'mydomain.com');

    expect(route('dashboard'))->toBe('http://mydomain.com/dashboard');
});

But this doesn't work:

Failed asserting that two strings are identical.
Expected :'http://mydomain.com/dashboard'
Actual   :'http://localhost/dashboard'

I also tested with a Pest describe + beforeEach, no success either:

describe('Dashboard paths modifications', function () {
    beforeEach(fn () => config()->set('my-package.domain', 'mydomain.com'));

    test("Dashboard domain can be modified", function () {
        expect(route('dashboard'))->toBe('http://mydomain.com/dashboard');
    });
});

I also tried to run route:clear in the test...
My ServiceProvider correctly registers route and config file (I test other stuff which confirms that point)

There is no example test that I could use in Telescope, maybe the reason is that it's too complicated to modify the routes before running a test?

LaryAI

1 year ago

Level 58

To test the modification of package configuration, especially when it involves routes, you need to ensure that the configuration is set before the routes are loaded. In Laravel, routes are typically loaded when the application boots up, so changing the configuration after the routes have been loaded won't affect them.

Here's a step-by-step solution to ensure your test works as expected:

Set Configuration Before Routes Are Loaded: Ensure that the configuration is set before the routes are loaded. You can achieve this by setting the configuration in a setUp method or using a beforeEach hook in Pest, but make sure it's done before the application boots.
Use a Custom Test Case: If you're using PHPUnit, you can create a custom test case that sets the configuration before the application boots.
Clear Cached Routes: If you have route caching enabled, make sure to clear the cached routes before running your tests.

Here's how you can structure your test:

// Custom Test Case for PHPUnit
use Illuminate\Foundation\Testing\TestCase as BaseTestCase;

abstract class TestCase extends BaseTestCase
{
    protected function setUp(): void
    {
        parent::setUp();

        // Set the configuration before the application boots
        config()->set('my-package.domain', 'mydomain.com');
        config()->set('my-package.path', 'dashboard');
    }
}

// Your test
test("Dashboard domain can be modified", function () {
    // Ensure the route is generated with the modified configuration
    expect(route('dashboard'))->toBe('http://mydomain.com/dashboard');
});

For Pest, you can use the beforeEach hook, but ensure it's executed before the application boots:

beforeEach(function () {
    // Set the configuration before the application boots
    config()->set('my-package.domain', 'mydomain.com');
    config()->set('my-package.path', 'dashboard');
});

test("Dashboard domain can be modified", function () {
    // Ensure the route is generated with the modified configuration
    expect(route('dashboard'))->toBe('http://mydomain.com/dashboard');
});

Ensure No Route Caching: Make sure that route caching is not interfering with your tests. You can run php artisan route:clear before running your tests to ensure no cached routes are used.

By setting the configuration before the application boots, you ensure that the routes are registered with the correct configuration values. This should resolve the issue you're facing with the test not reflecting the modified configuration.

Please or to participate in this conversation.