I recently discovered a queue-able job which batch generates PDF versions of pages was failing, but calling the problematic PDF versions individually (through the browser) was not failing so our test pipeline was passing.
After investigation we found this was caused by the Blade template referring to a method on Auth::user() because when called through a root via the browser, Auth::user() is available as a legitimate instance of the User model. However when the queue is run by Daemon, Auth::user() is null so the Blades were not rendering. This went unnoticed for several months because we thought our test coverage was sufficient by simply logging in as the user and loading the PDF versions individually.
The fix was easy. I just added checks that Auth::user() is not null before referring to it. However, referring to Auth::user() in a Blade is a perfectly normal practice and it's probable that more may be added in future.
How can I write test coverage that re-creates/simulates the conditions of code being called by Daemon? Either in Behat or PHPUnit, I don't mind.
I have tried calling Artisan like this...
Artisan::call('queue:work', [
'--tries' => 1,
'--timeout' => 4,
'--once'
]);
...but it just hangs forever!
I also tried whipping up an instance of the Queueable Job and calling the handle() method but it always succeeds, even when I introduce breaking code that fails when the queue is run through the CLI.
$user = User::find(26); // Our test user
$portfolio = $user->portfolios()->first();
$generatePortfolio = new GeneratePortfolio($learnerPortfolio);
$success = $generateLearnerPortfolio->handle();
return [
'success' => $success
];
Is there some way I can simulate how the QueueWorker calls the jobs and reliably fetch the result?
via Chebli Mohamed
Aucun commentaire:
Enregistrer un commentaire