GuillaumePacheco's avatar

Launch and schedule testing from Back Office

Hello everyone,

I'm trying to trigger the artisan test command from a back office, retrieve the output and send it back to the back office. (Laravel 9) The test command works perfectly in CLI.

To do this, I've created a run:test-app command that calls $this->call('test', ['--without-tty' => true, '--vvv' => true]);

When I hit the route that's supposed to trigger this command, I get the error message: Could not open input file: vendor/phpunit/phpunit/phpunit. (with any other artisan command it works)

Even weirder, when I schedule the artisan test command to play once a day, when the schedule is executed the artisan command returns different results than in CLI mode, and deletes all entries from my main db. I don't even see how this is possible, given that my test base is forced into my env.testing + phpunit.xml.

It's probably a config problem but i don't see my mistake with the laravel and phpunit's doc.

Has anyone seen similar behavior?

0 likes
8 replies
LaryAI's avatar
Level 58

The error message "Could not open input file: vendor/phpunit/phpunit/phpunit" suggests that the PHPUnit executable file is not found in the specified path. This could be due to a misconfiguration or missing dependencies.

To resolve this issue, you can try the following steps:

  1. Make sure that PHPUnit is installed as a dependency in your project. You can check your composer.json file to verify this. If it's not listed, you can add it by running the following command in your project root directory:
composer require --dev phpunit/phpunit
  1. After installing PHPUnit, try running the test command again from the CLI to ensure that it works as expected.

  2. Check the permissions of the vendor/phpunit/phpunit/phpunit file. Make sure it is readable and executable by the user running the command.

  3. Verify that the correct path to the PHPUnit executable is set in your Laravel configuration. Open the config/phpunit.php file and ensure that the phpunit key is set to the correct path. It should be something like:

'phpunit' => base_path('vendor/bin/phpunit'),
  1. If you're using Laravel's scheduler to run the tests, make sure that the scheduler is running with the correct environment. You can specify the environment in the schedule method of your App\Console\Kernel class. For example:
protected function schedule(Schedule $schedule)
{
    $schedule->command('test')->daily()->environments(['testing']);
}
  1. Double-check your phpunit.xml file to ensure that it is correctly configured for your testing environment. Make sure that the database connection and other relevant settings are properly set.

If you've followed these steps and the issue persists, it may be helpful to provide more details about your Laravel and PHPUnit versions, as well as any relevant code snippets or configuration files.

martinbean's avatar

@guillaumepacheco Why are you trying to do this from a route in the first place? You should be running tests in a CI environment.

There’s no point running tests from a “back office” if bad code and failing tests have already been deployed.

GuillaumePacheco's avatar

@martinbean Thanks for your reply. The aim is to set up a "health interface" for the site in the back office. Having these test results, and being able to refresh them from the interface, would be interesting in my opinion.

Obviously, this wouldn't replace the CI tests, but would be an additional feature.

But if you see a counter-indication, or even another solution to achieve this goal, I'm open to it.

krisi_gjika's avatar

@GuillaumePacheco if your tests passed on the CI they will pass again from your route. what is the point of retrying them? passing tests has nothing to do with the health of the site. site health usually refers to cpu / memory usage, response times, ect.

1 like
Snapey's avatar
Snapey
Best Answer
Level 122

running tests usually has its own environment, eg to prevent email being sent, to use a clean database that can be trashed between tests etc

How do you expect to run your tests using a test environment whilst at the same time running under a production environment?

I would drop this folly and get on with something more useful and valuable

GuillaumePacheco's avatar

After all your feedback, it seems there's no point in what I was trying to do. So I'm not going to continue with this attempt. Thank you all for your help.

Please or to participate in this conversation.