Tool or commands to seed data for testing.
Is your enhancement related to a problem? Please describe.
It's very nice to have a way to repopulate data like posts/pages/options before testing.
Designs
I'm thinking about using REST API to populate data in the setup phase. Each plugin will have its own set of fixture data. What I'm targeting for this library is creating tools to make the process easier.
Describe alternatives you've considered
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Some research:
- We can use
cy.requestto call the REST API with basic auth. - We can also use
cy.execto run the WP CLI script. - We can place the setup commands in a
beforehook within thecypress/support/index.jsto have it run once before all the tests.
After checking about login automation, I just need to comment on this:
We can place the setup commands in a before hook within the cypress/support/index.js to have it run once before all the tests.
With Cypress in cli mode, the before hook from support/index.js is called for every test suite. So we will have duplication of data with multiple suites.
@jeffpaul suggested investigating the wp post generate command for seeding data. But as Max mentioned above, we will need to find a way to make it rut once first.
A concept of the solution
A bash script which is called once (manually or via GitHub Actions), which do couple things:
- Seeds the data for testing with WP-CLI
- Saves created post(s) with IDs as fixtures which could be used inside Cypress tests later.
Now inside Cypress we get access to posts by IDs.
If the script is called twice for some reason, it will just duplicate testing data (which is not a problem) and will update fixtures file.
fixtures.sh
#!/bin/bash
SCRIPT_DIR=$(cd -- "$(dirname -- "${BASH_SOURCE[0]}")" &> /dev/null && pwd)
FIXTURES_FILE="$SCRIPT_DIR/../cypress/fixtures/post.json"
echo "Creating test content..."
TITLE="Test Post $RANDOM"
OUTPUT=$(npm run env run tests-cli "wp post create --post_title='$TITLE'")
TEXT=$(echo "$OUTPUT" | sed -r "s/\x1B\[([0-9]{1,3}(;[0-9]{1,2})?)?[mGK]//g")
if [[ $TEXT =~ (Created post )([0-9]+) ]]; then
MATCH="${BASH_REMATCH[2]}"
fi
echo "{\"title\": \"$TITLE\",\"id\": \"$MATCH\"}" > $FIXTURES_FILE
echo "Saved fixtures file."
Here's a sample of how we could seed with the WP-CLI "wp post generate" command:
Cypress.Commands.add('seedData', () => {
// Define the number of posts and pages to generate
const numPosts = 2;
const numPages = 2;
// Generate the sample posts and pages using WP-CLI
cy.exec(`wp post generate --count=${numPosts} --post_type=post --format=json`).then((result) => {
const postData = JSON.parse(result.stdout);
postData.forEach((post) => {
// Update the post status to "publish"
cy.exec(`wp post update ${post.ID} --post_status=publish`);
});
});
cy.exec(`wp post generate --count=${numPages} --post_type=page --format=json`).then((result) => {
const pageData = JSON.parse(result.stdout);
pageData.forEach((page) => {
// Update the page status to "publish"
cy.exec(`wp post update ${page.ID} --post_status=publish`);
});
});
// Define the sample data for options
const optionData = [
{
option_name: 'test_option_1',
option_value: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.',
},
{
option_name: 'test_option_2',
option_value: 'Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.',
},
];
// Create the sample options using WP-CLI
optionData.forEach((option) => {
cy.exec(`wp option add ${option.option_name} "${option.option_value}"`);
});
});
@jeffpaul while testing plugins, each plugin requires its own "state" of data, especially its own admin settings.
While working with RSA, I tested both WP-CLI and REST API and found the latter one to be a lot faster.
wp-env provides a way to load plugins, which I have used in RSA just to register REST endpoints which are called by Cypress to seed data as required.
Adding to that, seeding options with complex nested data is a real pain when using WP-CLI. Instead of providing a Cypress command, we can instead document how to create a plugin that registers REST endpoints to seed data. What do you think?
@Sidsector9 that seems reasonable, perhaps referencing an example or two might be sufficient here