Add E2E testing to track events across all page types

[mikkamp]

Changes proposed in this Pull Request:

With the focus on shifting towards blocks yet still supporting classic pages, we have to cover the following types of pages to track their events:

1. Traditional pages using the classic shortcodes.
2. Default WooCommerce pages which are created during install, most have been switched to blocks when starting with a new site.
3. The "Products (Beta)" block.
4. The "Product Collection (Beta)" block. This one is intended to replace the Products block.

To test this manually is a large burden. This PR copies over the E2E we have for tracking in GLA and modifies them to work with the GA events we send. This makes it easier to test the events across several different page/block types.

The tests in this PR did highlight some inconsitencies, and events that aren't being tracked, so the following changes are needed to make these tests pass:

• PR Get correct variation data when formatting product #384
• PR Fix - Selectors in Product Blocks #378
• Extra selector for Product Collection block mentioned in Fix - Selectors in Product Blocks #378 (comment)

Detailed test instructions:

1. Install any required patches as listed above
2. Install all npm dependencies nvm use && npm ci
3. Build assets either through npm start or npm run build
4. Ensure we don't have any conflicting E2E docker instances running (like the one from GLA)
5. Start the wp-env site npm run wp-env:up
6. Install browser (only needed once) npx playwright install chromium
7. Run tests npm run test:e2e
8. Confirm tests are successful

Note: workflow is included (direct copy from GLA). We can only trigger it once this PR is merged (unless you want to clone the repo to test it).

Additional details:

These test aim to cover the most common scenarios, but while testing I still came across the following inconsistencies/parts we aren't covering (these can be addressed in follow up PR's):

• Remove from cart with shortcode [woocommerce_cart] isn't always tracked because of immediate page redirect (not in E2E)
• Remove from cart / Begin checkout is not consistent between blocks and shortcode, category and variation data differ.
• Change cart quantity is not tracked with shortcode [woocommerce_cart] or with blocks (PR Remove unused function from formatters #375 removes it)
• Add shipping info doesn't seem to be used anywhere (mentioned in Remove unused function from formatters #375 (comment))
• Select content is difficult to test if it is followed up by a page redirect (no E2E tests written yet)
• begin_checkout logs total item price (including discounts and price * quantity), purchase logs product object price (not final price we paid in the order). Should these be consistent?
• When we hook into woocommerce_add_to_cart, should we get final price from cart_item_data? Otherwise we'll track product prices vs. discounted price.
• When we change the settings to redirect to cart page after add_to_cart, do we still capture all details?
• Testing with grouped / bundled products (grouped product seems to only track first product added to cart)

Changelog entry

• Dev - Add E2E testing to track events across all page types.

[tomalec]

📜 💅
If we're going to extract those to shared lib, we could consider all create*Page functions to return the created page id. to keep their behavior consistent

[ianlin]

I only verified if all the e2e tests were passed. Here's my step:

• Run e2e tests on this branch, most of the tests failed which is expected
• Check out a new branch based off this PR's branch dev/add-e2e-tests
• Merge origin/fix/add_to_cart_selector from Fix - Selectors in Product Blocks #378 into the new branch
• Merge origin/fix/get-data-for-variations from Get correct variation data when formatting product #384 into the new branch
• Update code locally based on Fix - Selectors in Product Blocks #378 (comment)

  --- a/assets/js/src/integrations/classic.js
  +++ b/assets/js/src/integrations/classic.js
  @@ -162,7 +162,9 @@ export function trackClassicPages( {
    // Handle selection and add_to_cart in **Block** product listing the classic way.
    // Attach click event listeners to a whole product card, as some links may not have the product_id data attribute.
    document
  -   .querySelectorAll( '.products-block-post-template .product' )
  +   .querySelectorAll(
  +     '.products-block-post-template .product, .wc-block-product-template .product'
  +   )
      ?.forEach( ( productCard ) => {
        // Get the Product ID from a child node containing the relevant attribute
        const productId = productCard

• Run e2e tests again, all tests passed except:

  6 [chromium] › gtag-events/blocks-pages.test.js:160:2 › GTag events on block pages › Add to cart event is sent from a product collection block shop page
  

  Which is related to the code change from Fix - Selectors in Product Blocks #378 (comment). Not sure if I change the code locally wrong?

I saw @tomalec started reviewing this PR as well I would leave the rest of the review to him for now. I would review the rest tomorrow if needed.

[mikkamp]

Run e2e tests again, all tests passed except:

[chromium] › gtag-events/blocks-pages.test.js:160:2 › GTag events on block pages › Add to cart event is sent from a product collection block shop page

Which is related to the code change from #378 (comment). Not sure if I change the code locally wrong?

The code you changed is right, did you rebuild the assets after that change? I'm not quite sure why it would be failing otherwise. Maybe you can check the site at http://localhost:8889 to see how it handles the "Product Collection Shop" page. Make sure to add some test settings to enable tracking, during E2E that's enabled and cleared.

[tomalec]

💅 Maybe instead of hardcoding its name, we could read it from config.products.simple.name?

[tomalec]

💅 Also, we could cache simpleProductID.toString() and simpleProductPrice.toString()in beforeAll

[mikkamp]

I agree, but also disagree here. I personally don't like to abstract too much information in the expect calls. I want to see clearly what data I'm expecting without having to look it up what it should match too. It's true that if they are constants then there is no harm as they can't be modified, but this is more personal preference. Ofcourse I'm breaking my own by not using a constant for simpleProductPrice, but that's mainly because I copied that logic from GLA.

For the same reason I don't often make a lot of the expect parts in tests "DRY", which could easily be done in this case since a lot of expect similar data.

[tomalec]

I can relate to being explicit in expects, so I'm fine leaving it as simpleProduct*.toString().

But for the same reason, I'd use config.products.simple.name as this is what we expect from the perspective of this file. We didn't set Simple product here. So we expect it to be "whatever is set in config"

[tomalec]

We're not returning the ID if the page exists.

Suggested change

	if ( ! ( await pageExistsByTitle( title ) ) ) {
	return await createPage( title, content );
	}
	return (
	( await pageExistsByTitle( title ) ) ||
	( await createPage( title, content ) )
	);

[tomalec]

Reviewed the code, run locally, LGTM
Left a few cosmetic comments.

Thank you very much! :) Having E2Es in place could boost the speed and confidence in our development :)

[tomalec]

❔ 💅

Why do we use /__fixtures__/ insted of /fixtures/? Do we autogenerate them somehow? If not, maybe we could format the content to be more readable.

[mikkamp]

No specific reasoning, I manually generated these.
Copied directly from GLA, where we initially copied it from the WC Blocks E2E tests. So I'm not tied to a particular method, I just needed something up and running.

[mikkamp]

@tomalec Thanks for the review. Since this is approved and working, I'm going to merge it so we can focus on the other issues and get them tested. We can always refactor / change any other details later if needed.