HTTP Testing of Plugin not possible
der-On opened this issue · 5 comments
Winter CMS Build
dev-develop
PHP Version
8.1
Database engine
SQLite
Plugins installed
No response
Issue description
I have a custom plugin with a routes.php file.
I've written a test that uses laravels HTTP Testing to test an endpoint from the routes.php file.
I use php artisan winter:test --plugin=My.Plugin to run it's tests.
The test request to any valid endpoint in that routes.php file returns the 404 page of the active theme.
The cause is that the plugin will not get registered under a PluginTestCase unless it is elevated: https://github.com/wintercms/winter/blob/develop/modules/system/classes/PluginManager.php#L338
The plugin and it's routes must get registered at this stage, to prevent the CMS routes beeing registered before the plugins routes.
So including the plugins routes manually in the test case wont work as it is too late in the process.
Steps to replicate
Create a plugin with routes.php
Create a plugin test case and use HTTP testing from Laravel (https://laravel.com/docs/9.x/http-tests#introduction) to run a test request against a route from routes.php of the plugin.
Use php artisan winter:test --plugin=Your.Plugin to run the test.
Workaround
Make the Plugin elevated: https://wintercms.com/docs/v1.2/docs/plugin/registration#elevated-permissions
@der-On this would be related to 71fcf8e, which itself is related to an issue reporting in October years ago.
Essentially, we had to disable the plugin register() method and routes.php and init.php files within plugins when running CLI commands (such as winter:test) if the database is either unavailable or hasn't yet been configured/migrated, as multiple people would run commands for environments such as Vapor without the database being made available yet and would encounter exceptions if a plugin used a database during registration.
Personally, I'm not a fan of the fix - I think plugin developers should be more responsible and not be calling the database during registration, but I digress, since it was reported commonly enough, we had to err on the side of caution.
One thing you could do - I don't know how difficult it would be with your setup - but you could run the migrations before the tests run. If the database is available and migrated before the tests are run, you would side-step this fix.
Alternatively, we could make it so that this fix is applied conditionally (enabled by default) and could be disabled by an option to the winter:test command, but I'm not a massive fan of that either.
@bennothommo I'm already running the tests after the database is migrated. This is actually part of the PluginTestCase setUp method by default.
@der-On have the migrations been run on the test database before you run the tests?
The reason I ask is because the function that disables plugin initialization (here in the code) specifically looks for whether the migration table is set up, as winter:test itself is not a privileged CLI command. In your unit tests, you would likely be using a different database connection.
@bennothommo As far as I can tell, It uses the test database. I however did create a config/testing/database.php.
Closing this for now as there's been no follow up. If the issue persists, please let us know and we'll re-investigate.