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

Added single VR test script along with updated configs for betterment #546

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

KosalaiV
Copy link
Contributor

@KosalaiV KosalaiV commented Jul 4, 2024

  • Added a single test script for VR that extracts endpoints from a .csv file.

  • Updated cypress.config.js with reporter configurations.

  • Created a config folder containing different environment base URLs for dynamic URL selection.

  • Enhanced support/e2e.js with after-run test actions.

Copy link
Member

@hussainweb hussainweb left a comment

Choose a reason for hiding this comment

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

Thanks for all the work here. I think we can rethink how to do a lot of things here to make it simpler for us and for the long term.

Comment on lines 7 to 8
// returning false here prevents Cypress from
// failing the test
Copy link
Member

Choose a reason for hiding this comment

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

Why don't you want to fail the test when there is a failure?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hussainweb That is specific for uncaught exceptions, most of the times cypress will fail due to that. Here's the reference

Comment on lines 16 to 29
Cypress.on('test:after:run', (test, runnable) => {
if (test.state === 'failed') {
let parent = runnable.parent;
let filename = '';
while (parent && parent.title) {
filename = `${titleToFileName(parent.title)} -- ${filename}`;
parent = parent.parent;
}
filename += `${titleToFileName(test.title)} (failed).png`;
addContext({ test }, `../screenshots/${Cypress.spec.name}/${filename}`);
}
// always add the video
addContext({ test }, `../videos/${Cypress.spec.name}.mp4`);
});
Copy link
Member

Choose a reason for hiding this comment

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

What does this do? Please put in a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hussainweb This is an after run configurations where it will generate an HTML report with attached execution videos and screenshots of the tests.

Comment on lines 3 to 4
require('cypress-grep')();
require('cypress-xpath');
Copy link
Member

Choose a reason for hiding this comment

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

Where are you using these?

parent = parent.parent;
}
filename += `${titleToFileName(test.title)} (failed).png`;
addContext({ test }, `../screenshots/${Cypress.spec.name}/${filename}`);
Copy link
Member

Choose a reason for hiding this comment

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

Isn't this something Cypress does by default?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, it seems this is done to pass data to mochawesome-report-generator. I suggest not using any reporter for now. we can evaluate and consider it later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is for the later use to provide an HTML report.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's have a separate discussion and PR for reporting. In this PR, we should only focus on writing tests. We can address reporting later on.

@@ -20,6 +22,14 @@
"breakpoint-sass": "^3.0.0",
"browser-sync": "^3.0.2",
"cypress": "13.12.0",
"cypress-grep": "^2.0.1",
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will update it.

Comment on lines 16 to 18
pageLoadTimeout: 500000,
requestTimeout: 90000,
responseTimeout: 90000,
Copy link
Member

Choose a reason for hiding this comment

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

These timeouts are really long for CI. Is there a reason for such long timeouts?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is simply a maximum limit; we likely don't want any tests to fail due to exceeding the page load time.

experimentalStudio: true,
trashAssetsBeforeRuns: false,
experimentalShadowDomSupport: true,
reporter: 'mochawesome',
Copy link
Member

Choose a reason for hiding this comment

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

How does this reporter help? I'd like to keep dependencies to a minimum if this is not important.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we need a reporter right now. Our focus should be on writing some test cases. We can worry about using a reporter later. Anyway, we have enough visibility of running tests in CI, and locally we can run the tests in interactive mode.

"mochawesome": "7.1.3",
"mochawesome-merge": "4.2.2",
"mochawesome-report-generator": "6.2.0",
"neat-csv": "5.1.0",
Copy link
Member

Choose a reason for hiding this comment

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

This package has not seen an update in 3 years. I am not comfortable with introducing this as a dependency. There is https://www.npmjs.com/package/csv-parse instead but I think we can avoid using CSV entirely. How about storing the URL's as JSON instead?

@@ -0,0 +1,12 @@
url,title
Copy link
Member

Choose a reason for hiding this comment

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

We don't need a CSV parser complicating our dependency tree for such a simple CSV file. In fact, we can just write a simple JS file returning a config array or a JSON file. Something like this:

{
  "Home": "/",
  "CodeContributions", "/code-contributions",
  // and so on...
}

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, let's not use CSV. We can use a JSON file or just hardcode the array in the spec file itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will go with JSON file

Copy link
Member

Choose a reason for hiding this comment

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

We have switched to JSON, right? Why still keep the CSV file?

},
video: true,
Copy link
Member

Choose a reason for hiding this comment

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

We don't want videos? Should we make this configurable? Anyway, it seems out of the scope for this PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hussainweb This would help a non-technical user to look through why the tests are failing. We'll see the video attached to the HTML report itself. Let me know your thoughts here.

Copy link
Member

Choose a reason for hiding this comment

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

@KosalaiV, it was a question. You are removing the line video: true and I presumed that this change will disable videos from being generated.

Copy link
Member

Choose a reason for hiding this comment

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

@KosalaiV,

Let's keep video: true for now,

So you're going to revert this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hussainweb Will be updating it with env variable like this:
video: process.env.CYPRESS_VIDEO !== 'false'

The plan is to not include videos for VR scripts, hence it defaults to true for the functional test cases

@@ -45,6 +55,8 @@
"uuid": "^10.0.0"
},
"dependencies": {
"cypress-split": "^1.24.0",
"@slack/web-api": "^6.11.2",
Copy link
Collaborator

Choose a reason for hiding this comment

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

Why are we using @slack/web-api package? Are we planning to send a notification to slack?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@zeshanziya Yes, this is for functional tests notification. Likely to attach screenshots of failures

Copy link
Collaborator

Choose a reason for hiding this comment

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

@KosalaiV Let's remove it for now. For Slack integration, we can have another PR. Our intention is to keep it simple, so only changes related to this PR should be included. Any additional changes can be added later. Let's work with small PRs so it's easier to review and merge faster.

@zeshanziya
Copy link
Collaborator

@KosalaiV, the CI checks are failing. Are you using the latest version of npm? Instead of using your local npm, have you tried setting up contrib-tracker on your local machine? Try using the command specified in the documentation; it will use the npm from the container, and you won't have to worry about updating your local npm. The documentation contains all the steps to run Cypress on your local machine.

},
video: true,
Copy link
Member

Choose a reason for hiding this comment

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

@KosalaiV, it was a question. You are removing the line video: true and I presumed that this change will disable videos from being generated.

Comment on lines 22 to 39
// describe('Check for .aspx links', { tags: '@functional' }, () => {
// it('should not contain any .aspx links', () => {
// cy.visit('https://waps-php.test.ohchr.org/',{failOnStatusCode: false}); // Replace with your actual URL

// cy.get('a[href*=".aspx"]').then($els => {
// if ($els.length > 0) {
// // Collect all .aspx links
// const aspxLinks = [];
// $els.each((index, el) => {
// aspxLinks.push(el.getAttribute('href'));
// });

// // Throw an error with all the found .aspx links
// throw new Error(`Found .aspx links on the page: ${aspxLinks.join(', ')}`);
// }
// });
// });
// });
Copy link
Member

Choose a reason for hiding this comment

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

This should be removed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ahh, Let me remove the commented code.

Let's keep video: true for now, @hussainweb. The intention is to identify any breakages and allow for review of what the test does. Videos make this process easier, and we'll attach the videos to the report.

However, for visual testing with Percy, the video configuration isn't necessary. But for others, it is a good to have one.
I'll add an environment variable setup to accept a boolean value for video.

Copy link
Member

Choose a reason for hiding this comment

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

@KosalaiV, please comment on the relevant line. The video: true line is elsewhere.

@@ -0,0 +1,12 @@
url,title
Copy link
Member

Choose a reason for hiding this comment

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

We have switched to JSON, right? Why still keep the CSV file?

@@ -45,6 +51,7 @@
"uuid": "^10.0.0"
},
"dependencies": {
"cypress-real-events": "^1.13.0",
Copy link
Member

Choose a reason for hiding this comment

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

Why is this not a dev dependency?

Comment on lines 36 to 45
"postcss": "^8.4.40",
"postcss": "^8.4.38",
Copy link
Member

Choose a reason for hiding this comment

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

@KosalaiV, why are you changing these dependencies?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@hussainweb I haven't changed this, but we did rebase with main and got some conflicts in package.json. That could be the cause.
cc: @zeshanziya

Copy link
Collaborator

Choose a reason for hiding this comment

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

@KosalaiV It seems we accepted the current change instead of the incoming changes while resolving the conflict. Please revert it to its original version.

@hussainweb
Copy link
Member

hussainweb commented Oct 24, 2024

@zeshanziya, can you help rebasing this one? I thought this change was combined into the other PR but I guess I was wrong.

@zeshanziya
Copy link
Collaborator

@hussainweb I believe this PR is old and includes changes that were split into smaller PRs, which have already been merged. Should I still attempt rebasing to check if any changes are pending? We removed the folder structure for test cases, so all test cases are now directly under the e2e folder. In this PR, they're still under e2e/Functional_tasks, which is why these tests are appearing as new additions.

@hussainweb
Copy link
Member

@zeshanziya, I agree about the tests. They will get rebased, of course, but we will end up with duplicate tests. Is there anything else in this PR that we should adopt? If not, let's close this PR.

Copy link

Npm packages

Package From To
prettier 3.3.2 3.3.3
@cypress/xpath NEW 2.0.3

@hussainweb
Copy link
Member

@zeshanziya, I rebased this and didn't see any changes left over. I am inclined to close this PR without merging but I wanted you to review once. cc @KosalaiV

@zeshanziya
Copy link
Collaborator

@hussainweb Yes, we can close this.

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.

3 participants