Eloquent model events are not triggered when testing

[PascalZajac]

The various Eloquent model events ending with ing are not being triggered during tests.

I discovered this a while ago and assumed it was intended functionality (forcing you to test your event handlers separately, much as route filters are not run in test mode).

However today I discovered that the post-action event handler created is triggered when run in test mode. Is there a reason for the discrepancy?

[PascalZajac]

Upon further investigation, the behaviour gets weirder. It seems like the model event only executes the very first time the action occurs within the test suite.

To explain my particular scenario: I have an Image model, and an associated ImageService which handles created and deleted events. When I first wrote the unit tests for the service, the model events were triggered correctly. I then added an ImageController, with tests covering creation of an Image via the controller. Suddenly, my ImageService tests began to fail. Disabling the tests for the ImageController would fix the ImageService tests, as would manually invoking the ImageService event methods within the ImageService test.

[taylorotwell]

Paste test.

On May 5, 2013, at 2:58 AM, Pascal Zajac notifications@github.com wrote:

Upon further investigation, the behaviour gets weirder. It seems like the model event only executes the very first time the action occurs within the test suite.

To explain my particular scenario: I have an Image model, and an associated ImageService which handles created and deleted events. When I first wrote the unit tests for the service, the model events were trigger correctly. I then added an ImageController, with tests covering creation of an Image via the controller. Suddenly, my ImageService tests began to fail. Disabling the tests for the ImageController would fix the ImageService tests, as would manually invoking the ImageService event methods within the ImageService test.

—
Reply to this email directly or view it on GitHub.

[PascalZajac]

Ok, this is the most succinct example I can produce:

    public function testFolderCreationAndDeletion()
    {
        // Create a new image.
        $image = Image::create(array());

        // Make sure a new folder was created.
        $path = ImageService::getPath($image);
        $this->assertTrue(is_dir($path)); // Passes.

        // Cleanup.
        $image->delete();
        $this->assertFalse(is_dir($path));
    }

    public function testAgain()
    {
        // Create a new image.
        $image = Image::create(array());

        // Make sure a new folder was created.
        $path = ImageService::getPath($image);
        $this->assertTrue(is_dir($path)); // Fails

        // Cleanup.
        $image->delete();
        $this->assertFalse(is_dir($path));
    }

The exact same test, if run again as a separate test, will fail where noted.

[taylorotwell]

Can you just paste the entire test class that fails?

On May 5, 2013, at 6:31 PM, Pascal Zajac notifications@github.com wrote:

Ok, this is the most succinct example I can produce:

public function testFolderCreationAndDeletion()
{
    // Create a new image.
    $image = Image::create(array());

    // Make sure a new folder was created.
    $path = ImageService::getPath($image);
    $this->assertTrue(is_dir($path)); // Passes.

    // Cleanup.
    $image->delete();
    $this->assertFalse(is_dir($path));
}

public function testAgain()
{
    // Create a new image.
    $image = Image::create(array());

    // Make sure a new folder was created.
    $path = ImageService::getPath($image);
    $this->assertTrue(is_dir($path)); // Fails

    // Cleanup.
    $image->delete();
    $this->assertFalse(is_dir($path));
}

The exact same test, if run again as a separate test, will fail where noted.

—
Reply to this email directly or view it on GitHub.

[PascalZajac]

use Instinct\Image;
use Instinct\User;

class ImageServiceTest extends TestCase {

    public function testFolderCreationAndDeletion()
    {
        // Create a new image.
        $image = Image::create(array());
        ImageService::created($image);

        // Make sure a new folder was created.
        $path = ImageService::getPath($image);
        $this->assertTrue(is_dir($path));

        // Cleanup.
        $image->delete();
        ImageService::deleted($image);
        $this->assertFalse(is_dir($path));
    }

    public function testEntityCleanup()
    {
        // Create a new image.
        $image = Image::create(array());
        ImageService::created($image);

        // Create a new user.
        $user = User::create(array(
            'image_id' => $image->id
        ));

        // Now delete the image.
        $image->delete();
        ImageService::deleted($image);

        // Reload the user and make sure the image was removed from their profile.
        $user = User::find($user->id);
        $this->assertEquals(0, $user->image_id);

        // Cleanup.
        $user->delete();
    }

}

That's the whole class, as it stands, including my manual invocations of ImageService methods (which should actually be triggered by event bindings, and are when run outside of a testing environment).

[PascalZajac]

I've done some further investigation on this. It seems that the Dispatcher class is re-instantiated between each test run. Some events, like artisan.start, are re-registered on each test run. However, Eloquent model events do not seem to be re-registered - they are registered once the first time the class is referenced anywhere in the test suite, and that's it.

[taylorotwell]

Honestly I don't get your test. You're passing model instances into the events methods. What is that even supposed to do?

[PascalZajac]

Ok, I think the class definition for the Image model may be relevant:

namespace Instinct;

class Image extends \Eloquent {

    /**
     * The database table used by the model.
     *
     * @var string
     */
    protected $table = 'images';

    /**
     * The fields that can be changed via mass assignment.
     * @var array
     */
    protected $fillable = array(
        'extension',
        'title',
        'description'
    );
}

// Register event handlers.
Image::created('ImageService@created');
Image::deleted('ImageService@deleted');

As you can see, in the model's class file I'm defining two event handlers. When an Image model is created, I want a folder to be created on the file system to handle the actual image which will soon be uploaded. When an Image is deleted, I want to remove the files from disk and delete the folder.

Now comes my assumption: since I create the event handlers in the model class file, they are not being reloaded between tests because composer does a require_once on the file. Thereafter it already has the class definition, so the file is never reloaded, and the event bindings are never recreated.

So it seems like the problem isn't with Laravel's event system but rather with where I'm defining my event bindings. Doing so in the model's class file seemed logical so they were clearly grouped together. Is there somewhere else I should put these sort of bindings?

[PascalZajac]

I read back over the documentation for Eloquent events and saw the static boot method (that I had somehow not noticed before). So I duly moved my event bindings into the boot method for each model, but the problem persists - the boot code is only run the first time the model is encountered in the test suite, but the event dispatcher is re-instantiated between each test.

Is there a reason for resetting the event dispatcher?

[taylorotwell]

I would move your event bindings into a separate method like Image::registerEvents(); and then you can call that from the setUp method.

[PascalZajac]

That creates a different set of problems though - the boot method is still called the first time the model is referenced in the test suite, so in the first unit test that uses the class, if you have a setUp method as well, two event listeners will be created.

I appreciate that we've travelled far from the original assertions of this ticket, so I'm happy to open a new one, but the underlying issues remain unresolved - either the Dispatcher class needs to discard attempts to register the same event handler twice, or the Dispatcher should not be re-instantiated between test executions. I'm not sure which is better/possible.

[taylorotwell]

Could also use Model::flushModelEvents to clear them out.

On May 17, 2013, at 11:20 PM, Pascal Zajac notifications@github.com wrote:

That creates a different set of problems though - the boot method is still called the first time the model is referenced in the test suite, so in the first unit test that uses the class, if you have a setUp method as well, two event listeners will be created.

I appreciate that we've travelled far from the original assertions of this ticket, so I'm happy to open a new one, but the underlying issues remain unresolved - either the Dispatcher class needs to discard attempts to register the same event handler twice, or the Dispatcher should not be re-instantiated between test executions. I'm not sure which is better/possible.

—
Reply to this email directly or view it on GitHub.

[PascalZajac]

Ah ok, that method (which is actually Model::flushEventListeners) hadn't been added the last time I updated. That's neater, now I can just maintain an array of classes to flush and reboot between tests where I need to. Thank you.