Make Behat scenarios SQLite-compatible#138
Conversation
|
Hello! 👋 Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project. Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation. Here are some useful Composer commands to get you started:
To run a single Behat test, you can use the following command: # Run all tests in a single file
composer behat features/some-feature.feature
# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123You can find a list of all available Behat steps in our handbook. |
There was a problem hiding this comment.
Code Review
This pull request enhances SQLite compatibility for export feature tests by removing MySQL-specific tags and replacing SQL-specific functions with PHP equivalents via wp eval. It also implements dynamic post ID lookups to handle non-sequential auto-increment behavior. Feedback was provided to consolidate multiple wp eval calls into a single command to optimize performance by reducing WordPress bootstrap overhead.
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
Updates the Behat acceptance tests for the export command to run successfully under WP_CLI_TEST_DBTYPE=sqlite by removing MySQL-specific assumptions in two scenarios.
Changes:
- Makes the “starting post ID” export scenario deterministic by deriving the start ID from the generated posts instead of hardcoding it.
- Replaces a MySQL-only
REPEAT()usage in a fixture with a SQLite-compatiblewp eval+str_repeat()approach. - Removes
@require-mysqlfrom the two affected scenarios so they execute under SQLite.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
With this PR, all the MySQL 5.6/5.7 are timing out. This needs investigating. |
The split-dump scenario remains MySQL-only because it tests MySQL's redo log size limit behavior, which doesn't apply to SQLite.
|
Fixed. The While I was in there I also went through the rest of the All CI jobs pass! ✅ |
Fixes #112
A bunch of scenarios in
features/export.featureare tagged@require-mysql, but the command source uses portable SQL and$wpdbeverywhere. The SQLite integration plugin has matured since that tag was added, and most of those scenarios work fine on SQLite today. This PR removes the tag where it isn't needed.Changes
19 scenarios drop the
@require-mysqltag. Verified by running the whole file withWP_CLI_TEST_DBTYPE=sqlite composer behat: 32 scenarios pass, 560 steps.Scenario: Export posts from a given starting post IDswitched from--start_id=6towp post list --offset=5 --posts_per_page=1 --format=ids. SQLite doesn't reset auto-increment onwp site empty, so the IDs aren't always 1..10 and the hardcoded value was matching 8 posts instead of 5.Scenario: Export without splitting the dumpkeeps@require-mysql. The scenario literally tests MySQL's redo log size limit ("stay below 10% of default redo log size of 48MB"), so making it work on SQLite doesn't make sense. I tried swappingREPEAT()forstr_repeat()earlier in this PR and it hung MySQL 5.6/5.7 CI for 47 minutes. Reverted.Related: wp-cli/.github#94