PhpUnit tests: Application Differences in between tests, Artisan commands breaks mocking

[growsphere]

Laravel Version

12.2.0

PHP Version

8.2.27

Database Driver & Version

sqlite3 3.37.2

Description

Since laravel11 (at least I couldn't reproduce the issue in L10), I have found some issues in phpunit tests with laravel.

There seem to be substantial differences in the application when the context is a single phpunit test (or the first test
of many when ran together) or a subsequent test. This is most likely due to the way the application is bootstrapped and/or reset between tests.

Tests that succeed in isolation then fail when run together with at least one other test, unless they happen to be the very first test that runs.

Examples:

• testing how many events are set up in the application schedule only works in the first test that runs
• mocking dependencies stops working after artisan commands are called from the test code.

In the linked repository (see steps to reproduce) I have provided examples and a more detailed description of the issue.

Steps To Reproduce

Demonstration: https://github.com/growsphere/laravel-bug-report-test-application
Edit: new repo following the requested requirements: https://github.com/growsphere/bug-report

All detailed steps are described in the readme of that repository.

[crynobone]

Hey there, thanks for reporting this issue.

We'll need more info and/or code to debug this further. Can you please create a repository with the command below, commit the code that reproduces the issue as one separate commit on the main/master branch and share the repository here?

Please make sure that you have the latest version of the Laravel installer in order to run this command. Please also make sure you have both Git & the GitHub CLI tool properly set up.

laravel new bug-report --github="--public"

Do not amend and create a separate commit with your custom changes. After you've posted the repository, we'll try to reproduce the issue.

Thanks!

[growsphere]

Hi, here is the requested repository
https://github.com/growsphere/bug-report

I'll edit the original Issue description to include this link

thank you!

[noefleury]

Issue 1

Hi,

I've investigate a bit and the first test just work by luck as you have the RefreshDatabase trait on your base TestCase class.

During the first test, it will run your migrations through Artisan. Then, for each next tests, schedule events callback will just never be loaded that's why you'll see 0 event.

On dirty way to make it work is by asking something linked to Artisan so it will trigger Artisan app creation which include your schedule events, see :

framework/src/Illuminate/Foundation/Console/Kernel.php

Line 540 in 8f3f0fd

$this->artisan = (new Artisan($this->app, $this->events, $this->app->version()))

Method all() will trigger getArtisan() singleton :

    protected function setUp(): void
    {
        parent::setUp();
        $this->app->make(Kernel::class)->all();
    }

[noefleury]

Issue 2

Just check this now and the issue is coming from your code.

This code should be removed :

public function __construct(protected ClassToBeInjected $injected)
{
    parent::__construct();
}

Using __construct in Command is a bad practice as each time you run an artisan command, constructor of every commands will be called. And by the way it look like the injection is not working as expected from constructor.

You should instead do that :

public function handle(ClassToBeInjected $injected): int
{
    $this->info($injected->sayHello());
    return self::SUCCESS;
}

[growsphere]

Hi! Thx for the feedback.
I can confirm that moving the injection from the constructor to the handle method) resolves the injection issue.

However, calling
$this->app->make(Kernel::class)->all(); in the setup of the Schedule test doesn't resolve the issue, the second test still fails for me, unless I remove the RefreshDatabase too.
Even if it worked, isn't that more of a "hack"? It doesn't look like expected or intended behavior, or is it?

With the goal of testing that the schedule is set up correctly in the project, writing a unit test that works with the scheduled events seems natural, and it shouldn't matter if it's the first test in the sequence or not. There should be a way of getting the schedule just like how it is intantiated within the real application. The question is how.