woocommerce/plugins/woocommerce-blocks/tests/e2e-tests/fixtures/fixture-loaders.js

317 lines
8.2 KiB
JavaScript
Raw Normal View History

/**
* External dependencies
*/
const WooCommerceRestApi = require( '@woocommerce/woocommerce-rest-api' )
.default;
const glob = require( 'glob-promise' );
const { dirname } = require( 'path' );
const { readJson } = require( 'fs-extra' );
const axios = require( 'axios' ).default;
require( 'dotenv' ).config();
/**
* Internal dependencies
*/
const fixtures = require( './fixture-data' );
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
// global.process.env.WORDPRESS_BASE_URL = `${ process.env.WORDPRESS_BASE_URL }:8889`;
/**
* ConsumerKey and ConsumerSecret are not used, we use basic auth, but
* not providing them will throw an error.
*/
const WooCommerce = new WooCommerceRestApi( {
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
url: `${ process.env.WORDPRESS_BASE_URL }/`,
consumerKey: 'consumer_key', // Your consumer key
consumerSecret: 'consumer_secret', // Your consumer secret
version: 'wc/v3',
axiosConfig: {
auth: {
username: process.env.WORDPRESS_LOGIN,
password: process.env.WORDPRESS_PASSWORD,
},
},
} );
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
const WPAPI = `${ process.env.WORDPRESS_BASE_URL }/wp-json/wp/v2/pages`;
/**
* prepare some store settings.
*
* @param {Object[]} fixture An array of objects describing our data, defaults
* to our fixture.
* @return {Promise} return a promise that resolves to the created data or
* reject if the request failed.
*/
const setupSettings = ( fixture = fixtures.Settings() ) =>
WooCommerce.post( 'settings/general/batch', {
update: fixture,
} );
/**
* Create taxes.
*
* @param {Object[]} fixture An array of objects describing our data, defaults
* to our fixture.
* @return {Promise} a promise that resolves to an array of newly created taxes,
* or rejects if the request failed.
*/
const createTaxes = ( fixture = fixtures.Taxes() ) =>
WooCommerce.post( 'taxes/batch', {
create: fixture,
} ).then( ( response ) =>
response.data.create.map( ( taxes ) => taxes.id )
);
/**
* Delete taxes.
*
* @param {number[]} ids an array of taxes IDs to delete.
*
* @return {Promise} return a promise that resolves to the deleted data or
* reject if the request failed.
*/
const deleteTaxes = ( ids ) =>
WooCommerce.post( 'taxes/batch', {
delete: ids,
} );
/**
* Create Coupons.
*
* @param {Object[]} fixture An array of objects describing our data, defaults
* to our fixture.
* @return {Promise} a promise that resolves to an array of newly created coupons,
* or rejects if the request failed.
*/
const createCoupons = ( fixture = fixtures.Coupons() ) =>
WooCommerce.post( 'coupons/batch', {
create: fixture,
} ).then( ( response ) =>
response.data.create.map( ( coupon ) => coupon.id )
);
/**
* Delete coupons.
*
* @param {number[]} ids an array of coupons IDs to delete.
*
* @return {Promise} return a promise that resolves to the deleted data or
* reject if the request failed.
*/
const deleteCoupons = ( ids ) =>
WooCommerce.post( 'coupons/batch', {
delete: ids,
} );
/**
* Create Products.
*
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
* currently this only creates a single product for the sake of reviews.
*
* @todo add more products to e2e fixtures data.
*
* @param {Object[]} fixture An array of objects describing our data, defaults
* to our fixture.
* @return {Promise} a promise that resolves to an array of newly created products,
* or rejects if the request failed.
*/
const createProducts = ( fixture = fixtures.Products() ) =>
WooCommerce.post( 'products/batch', {
create: fixture,
} ).then( ( products ) => {
return products.data.create.map( ( product ) => product.id );
} );
/**
* Delete products.
*
* Deleting products will also delete review.
*
* @param {number[]} ids an array of products IDs to delete.
*
* @return {Promise} return a promise that resolves to the deleted data or
* reject if the request failed.
*/
const deleteProducts = ( ids ) =>
WooCommerce.post( 'products/batch', {
delete: ids,
} );
/**
* Create Reviews.
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
*
* This is not called directly but is called within createProducts.
*
* @param {number} id product id to assign reviews to.
* @param {Object[]} fixture An array of objects describing our reviews, defaults
* to our fixture.
* @return {Promise} a promise that resolves to an server response data, or
* rejects if the request failed.
*/
const createReviews = ( id, fixture = fixtures.ReviewsInProduct( id ) ) =>
WooCommerce.post( 'products/reviews/batch', {
create: fixture,
} );
/**
* Enable Cheque payments.
*
* This is not called directly but is called within enablePaymentGateways.
*
* @return {Promise} a promise that resolves to an server response data, or
* rejects if the request failed.
*/
const enableCheque = () =>
WooCommerce.post( 'payment_gateways/cheque', {
enabled: true,
} );
/**
* Enable Paypal payments.
*
* This is not called directly but is called within enablePaymentGateways.
*
* @return {Promise} a promise that resolves to an server response data, or
* rejects if the request failed.
*/
const enablePaypal = () =>
WooCommerce.post( 'payment_gateways/paypal', {
enabled: true,
} );
/**
* Enable payment gateways.
*
* It calls other individual payment gateway functions.
*
* @return {Promise} a promise that resolves to an array of server response
* data, or rejects if the request failed.
*/
const enablePaymentGateways = () =>
Promise.all( [ enableCheque(), enablePaypal() ] );
/**
* Create shipping zones.
Switch to use `wp-env` as the development/test environment (https://github.com/woocommerce/woocommerce-blocks/pull/2730) * Switch to use wp-env * fix travis config * fix spacing? * doh need to install packages before starting environment! * more fixes for errors in travis environment * hmm still have node-git issues * nope must use dash * maybe it’s a caching issue (we’re caching node_modules?) * remove configs * add wp-env override json to gitignore * remove obsolete scripts * fix config in travis * restore default env (for phpunit) * for e2e manually set WORDPRESS_BASE_URL * doh fix variable for wp version * run phpunit via docker and fix WordPress version used for tests * find out what’s going on with this thing * don’t escape? * doh phpunit needs dev installed from composer! * fix versions * looks liek we have to make sure wp db is up to date?!? - also moves pre-configuration stuff all into one file for easier maintenance. * see if I can get insight into what the siteurl is in the wp environment on travis * try env setup (known that will break phpunit but possible it might fix e2e?) * output plugin list to see what is active in travis * try flushing rules * do a hard fulsh * fix argument syntax * move things around and add pre-configuration as files so all wp commands run at once * revert back to running each container command separately Not sure, but this might affect permissions issues? * maybe re-ordering before the file sync will help? also try some configuration changes * another attempt at travis config In this attempt: - map .htaccess to the server on the environment start - try changing permissions of wp-content and wp-content/plugins as a part of the e2e test bootup * use default wp version for gute build * refactor to run all wp commands in one go * don’t return promise from setup function - this might fix the sporadic fails related to the fixtures being setup (and potential race conditions there). * make sure we activate gutenberg plugin (previously we were just installing) The syntax of the command was incorrect. * try alternative syntax for installing and activating plugin
2020-06-17 20:28:11 +00:00
*
* Shipping locations need to be assigned to a zone, and shipping methods need
* to be assigned to a shipping location, this create a shipping zone and
* location and methods.
*
* @param {Object[]} fixture An array of objects describing our data, defaults
* to our fixture.
* @return {Promise} a promise that resolves to an array of newly created shipping
* zones IDs, or rejects if the request failed.
*/
const createShippingZones = ( fixture = fixtures.Shipping() ) => {
return Promise.all(
fixture.map( ( { name, locations, methods } ) => {
return WooCommerce.post( 'shipping/zones', { name } )
.then( ( response ) => {
return response.data.id;
} )
.then( ( zoneId ) => {
const locationsPromise = WooCommerce.put(
`shipping/zones/${ zoneId }/locations`,
locations
);
return [ zoneId, locationsPromise ];
} )
.then( ( [ zoneId, locationsPromise ] ) => {
const methodPromise = Promise.all(
methods.map( ( method ) =>
WooCommerce.post(
`shipping/zones/${ zoneId }/methods`,
method
)
)
);
return [ zoneId, methodPromise, locationsPromise ];
} )
.then( ( [ zoneId, methodPromise, locationsPromise ] ) =>
Promise.all( [ methodPromise, locationsPromise ] ).then(
() => zoneId
)
);
} )
);
};
/**
* Delete Shipping zones.
*
* Deleting a shipping will also delete location and methods defined within it.
*
* @param {number[]} ids an array of shipping zones IDs to delete.
*
* @return {Promise} return a promise that resolves to an array of deleted data or
* reject if the request failed.
*/
const deleteShippingZones = ( ids ) => {
const deleteZone = ( id ) =>
WooCommerce.delete( `shipping/zones/${ id }`, {
force: true,
} );
return Promise.all( ids.map( deleteZone ) );
};
const createBlockPages = () => {
return glob( `${ dirname( __filename ) }/../specs/**/*.fixture.json` ).then(
( files ) => {
return Promise.all(
files.map( async ( filePath ) => {
const file = await readJson( filePath );
const { title, pageContent: content } = file;
return axios
.post(
WPAPI,
{
title,
content,
status: 'publish',
},
{
auth: {
username: process.env.WORDPRESS_LOGIN,
password: process.env.WORDPRESS_PASSWORD,
},
}
)
.then( ( response ) => response.data.id );
} )
);
}
);
};
const deleteBlockPages = ( ids ) => {
return Promise.all(
ids.map( ( id ) =>
axios.delete( `${ WPAPI }/${ id }`, {
params: {
force: true,
},
auth: {
username: process.env.WORDPRESS_LOGIN,
password: process.env.WORDPRESS_PASSWORD,
},
} )
)
);
};
module.exports = {
setupSettings,
createTaxes,
deleteTaxes,
createCoupons,
deleteCoupons,
createProducts,
deleteProducts,
createReviews,
enablePaymentGateways,
createShippingZones,
deleteShippingZones,
createBlockPages,
deleteBlockPages,
};