First pass at Behat integration tests for Solr Power #95
Conversation
|
#84 is going to conflict with this PR's dependencies, so I haven't added them yet. |
|
@stevector This is ready for a review. Note: I didn't commit the changes to the |
| override: | ||
| - ./bin/behat-test.sh | ||
| post: | ||
| - ./bin/behat-cleanup.sh |
There was a problem hiding this comment.
@danielbachhuber Can you comment this out until tests are passing?
There was a problem hiding this comment.
Here's the source of the failure:
What should we do about the vendor directory generally?
There was a problem hiding this comment.
From our meeting yesterday with @ataylorme we agreed to that the ideal set up for the vendor dir would be:
- No vendor directory in github.
- Treat wordpress.org's SVN as a repository of build artifacts that would include the full vendor directory.
- Some degree of automation sending build artifacts to SVN in response to tags on github.
However, right now our master branch here on github does have the vendor directory fully committed. I think for the scope of this PR we should not be changing anything related to the vendor directory unless we have to. The initial PR should simply automate (what I assume is) an already functional set of install instructions.
Having never installed this plugin myself, I'm not certain if this failure is because something in the vendor directory needs to change or something in the set up script needs to change.
There was a problem hiding this comment.
Treat wordpress.org's SVN as a repository of build artifacts that would include the full vendor directory.
How do we accommodate the fact that some dependencies are only for testing (e.g. development), and don't make sense in the final build artifact?
Having never installed this plugin myself, I'm not certain if this failure is because something in the vendor directory needs to change or something in the set up script needs to change.
@ataylorme Mind taking a look at this failure and weighing in with your thoughts?
There was a problem hiding this comment.
How do we accommodate the fact that some dependencies are only for testing (e.g. development), and don't make sense in the final build artifact?
We use Composer's distinction between require and require-dev. When building for SVN we would use composer install --no-dev
We have a mishmash of dependencies right now, which means `composer install` isn't safe to run before the plugin has been pushed.
|
@stevector @ataylorme Fixed this up. Could I get a #reviewmerge so I can move on, and we can fix the failed builds on the other PRs? |
@danielbachhuber Thanks for this. The tests in Once we merge the facet widget we will want to expand tests to include indexing and searching for results but that's more of a would like to have. The current checks that the plugin is loaded by visiting the options page and that Solr is available are good for now. |
See #79