-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setup Unit tests #28
Setup Unit tests #28
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💯
* @subpackage Tests | ||
*/ | ||
|
||
it( 'should load the SP version', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is so cool to see, very glad you kept at it!
Co-authored-by: Sean Fisher <[email protected]>
Co-authored-by: Sean Fisher <[email protected]>
Co-authored-by: Sean Fisher <[email protected]>
@kevinfodness Could you update the branch settings with the new Github Actions? |
@renatonascalves branch protection rules have been updated. |
@@ -15,6 +15,9 @@ | |||
use Elasticsearch_Extensions\Controller; | |||
use Elasticsearch_Extensions\Registry; | |||
|
|||
// Load Composer dependencies. | |||
require_once __DIR__ . '/vendor/wordpress-autoload.php'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how people are adding/installing this plugin but I'd assume this change would break their sites (in case they pull directly from GitHub).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would it break their sites? Because they need to run composer install
on it?
It should be installed as a plugin via composer, although it could be submoduled, but in any case, needing to run composer install
on it is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool! Thanks for the confirmation.
But yes, my concern was a site could be using the plugin without using composer
. Pulling the latest would cause a fatal error since the vendor
folder would not exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we ever get around to publishing this on WordPress.org we will add a step that installs the vendor folder and includes that in what is sent to the WP.org SVN repo (as well as removing some development files that wouldn't be needed in a production install). But for now it's fine to leave as-is. You might want to add a note in the README about needing to run composer install
if that's not there already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me—thanks for putting this together. I'm sure we'll iterate on it as we get into writing tests, but this is a great starting point and enables us to be able to start writing tests for our adapters. 🍣
"wpackagist-plugin/elasticpress": "^4.2", | ||
"yoast/phpunit-polyfills": "^1.0" | ||
}, | ||
"scripts": { | ||
"phpcbf": "phpcbf .", | ||
"phpcs": "phpcs .", | ||
"phpunit": "phpunit", | ||
"phpunit": "@test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't bother aliasing this, just run composer test
. That will need to be updated in the GitHub actions for tests as well, if it isn't already.
@@ -15,6 +15,9 @@ | |||
use Elasticsearch_Extensions\Controller; | |||
use Elasticsearch_Extensions\Registry; | |||
|
|||
// Load Composer dependencies. | |||
require_once __DIR__ . '/vendor/wordpress-autoload.php'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would it break their sites? Because they need to run composer install
on it?
It should be installed as a plugin via composer, although it could be submoduled, but in any case, needing to run composer install
on it is fine.
<directory prefix="test-vip-search" suffix=".php">./tests/adapters/vip-search/</directory> | ||
</testsuite> | ||
|
||
<testsuite name="plugin"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this - a way to run generic tests and also tests for specific adapters.
'pre_option_upload_path', | ||
function () { | ||
return ABSPATH . 'wp-content/uploads'; | ||
define( 'ELASTICSEARCH_EXTENSIONS_TESTS_DIR', dirname( __DIR__ ) . '/tests/' ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really just __DIR__
. Rather than establishing a separate constant here, I'd rather just use __DIR__
below.
Mantle\Testing\manager() | ||
->before( function() { | ||
// Define bootstrap helper functions. | ||
require_once ELASTICSEARCH_EXTENSIONS_TESTS_DIR . '/includes/bootstrap-functions.php'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example:
require_once ELASTICSEARCH_EXTENSIONS_TESTS_DIR . '/includes/bootstrap-functions.php'; | |
require_once __DIR__ . '/includes/bootstrap-functions.php'; |
@renatonascalves I merged this because the config for required status checks on other PRs expects the status checks defined here. If you'd like to implement my suggestions from code review, you can do so in a separate PR. Thanks again for putting these tests together! |
Pest will inform the available adapters:
Here is how one can run tests per adapter:
VIP Search Adapter
SearchPress Adapter
Note: the recommendation is to use the
--testsuite
param since one can forget to add the--group
to a new unit test file.