Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(e2e): Enhance end-to-end testing and CI configuration #214

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

htuzel
Copy link
Collaborator

@htuzel htuzel commented Dec 18, 2024

What is Changed

  • Now e2e tests supports master model record level, too
  • Updated e2e.sh to support multiple test configurations for variation and master-level products, ensuring required environment variables are set before running tests.
  • Modified GitHub Actions CI workflow to include TEST_MASTER_PRODUCT_ID and added matrix strategy for running frontend tests with different record models and index prefixes.
  • Introduced new Cypress test file frontend.cy.js for Algolia search scenarios, replacing the deleted variation.cy.js.
  • Updated importPreferences.js to dynamically set preferences based on the record model.
  • Enhanced variation_index.test.js to handle product searches based on the current record model.

Internal documentation is here

Need to add TEST_MASTER_PRODUCT_ID and CODE_VERSION to GitHub vars for running tests correctly

@htuzel htuzel requested a review from sbellone December 18, 2024 15:04
@htuzel htuzel self-assigned this Dec 18, 2024
- Updated `package.json` to replace the `test:e2e` script with a new `e2eTest.js` script for improved end-to-end testing.
- Added multiple new npm scripts for e2e testing, including cleanup, linting, unit tests, and code preparation.
- Refactored GitHub Actions CI workflow to streamline e2e testing process, replacing the previous build job with a dedicated `e2e-tests` job.
- Introduced `e2eTest.js` script to encapsulate the e2e testing logic, including cleanup and error handling.
- Enhanced `importPreferences.js` to provide more informative logging during directory creation.
Copy link
Collaborator

@sbellone sbellone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I haven't fully reviewed but I've already spotted too multiple weird things for which I'll need answers.

The main thing would be: what's the point grouping everything in a single and big JavaScript file? And then using weird mechanism like calling npm commands from it?
If your E2E tests depend on other npm scripts, you can do things like that:

{
  "scripts": {
    "compile:js": "sgmf-scripts --compile js",
    "test:e2e": "npm run compile:js && ./scripts/e2eTest.js"
  }
}

Comment on lines +34 to +37
"e2e:import-preferences": "npm run import:preferences",
"e2e:run-sfcc-job": "npm run run:sfcc-job",
"e2e:variation-index-test": "npm run test:variationindex",
"e2e:frontend-test": "npm run test:frontend"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the benefit of duplicating the scripts like that?

Comment on lines +45 to +46
- name: Make e2eTest.js executable
run: chmod +x scripts/e2eTest.js
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not needed, you've already committed it with execution rights

"test:e2e": "./scripts/e2eTest.js",
"test:variationindex": "jest --testPathPattern='test/e2e/variation_index.test.js'",
"e2e:cleanup": "rm -rf e2e-tests e2e-tests.zip site_import.zip site_import \"$CODE_VERSION\" \"$CODE_VERSION.zip\"",
"e2e:check-codeversion": "if [ -z \"$CODE_VERSION\" ]; then echo 'ERROR: CODE_VERSION is not set. Please define it in your .env file or export it in your shell.'; exit 1; fi",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the reason of doing it like that?
Calling an npm command from a Node child_process to check an env var is really weird.
For other env vars, you simply check process.env[varName], why can't you do the same for CODE_VERSION?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This script is not used anywhere anymore, is it on purpose?

}

function lintJS() {
execSync('npm run e2e:lint', { stdio: 'inherit' });
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Linting is not related to E2E, why doing it here?

}

function runUnitTests() {
execSync('npm run e2e:unit', { stdio: 'inherit' });
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unit tests are unit tests, I don't get why you are mixing everything in a single JavaScript file.

}

function deployCode() {
execSync('npm run e2e:deploy-code', { stdio: 'inherit' });
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit crazy: the npm script executes a JavaScript file. Why not require it directly?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants