Added integeration test for LoginView page

[khushpatel173]

Issue:

Ref #2923

Added Integration test for LoginView.tsx page

Changes:

Adds an integration test file client/modules/User/pages/LoginView.integration.test.jsx covering:

• Rendering of page headings, divider, and social authentication buttons (GitHub & Google)
• Rendering of embedded LoginForm inputs (username/email, password, submit button)
• Link attributes and client-side navigation to /signup and /reset-password
• Form submission flow verifying that validateAndLoginUser action is invoked with the entered credentials

Demo:

It fails if i change something lets say if i change the redirect link to something else rather than /signup

I have verified that this pull request:

• has no linting errors (npm run lint)
• has no test errors (npm run test)
• has no typecheck errors (npm run typecheck)
• is from a uniquely-named feature branch and is up to date with the develop branch.
• is descriptively named and links to an issue number, i.e. Fixes #123
• meets the standards outlined in the accessibility guidelines

[welcome]

🎉 Thanks for opening this pull request! Please check out our contributing guidelines if you haven't already.

[khushpatel173]

@lindapaiste Please review this , also if it looks good then i can write tests for other User pages as well

[clairep94]

@khushpatel173 thanks for this!
Not sure if this qualifies as an integration test since it mocks in the test setup instead of creating a state.
It would still be useful but I think this is more of a unit test

[khushpatel173]

@khushpatel173 thanks for this! Not sure if this qualifies as an integration test since it mocks in the test setup instead of creating a state. It would still be useful but I think this is more of a unit test

Yes , you are correct this is a unit test , should i try to change it to a integeration test like what i can check is by sending a real network request in the login with some data i can check weather its actually changing the store as user authenticated true or not and then check weather the user was redirected or not , and can also check by sending invalid credentials and can check that it doesnt change the state in store , does this way sounds correct?? or should i just keep it as it as and rename it to a unit test

[clairep94]

@khushpatel173 thanks for this! Not sure if this qualifies as an integration test since it mocks in the test setup instead of creating a state. It would still be useful but I think this is more of a unit test

Yes , you are correct this is a unit test , should i try to change it to a integeration test like what i can check is by sending a real network request in the login with some data i can check weather its actually changing the store as user authenticated true or not and then check weather the user was redirected or not , and can also check by sending invalid credentials and can check that it doesnt change the state in store , does this way sounds correct?? or should i just keep it as it as and rename it to a unit test

I would say just renaming is sufficient. I believe the behaviour you're describing is covered in the e2e tests @Geethegreat could you confirm?

[Geethegreat]

Yes the check for successful logins and redirects has already been covered in the e2e tests- e2e/specs/login.spec.ts

[khushpatel173]

@khushpatel173 thanks for this! Not sure if this qualifies as an integration test since it mocks in the test setup instead of creating a state. It would still be useful but I think this is more of a unit test

Yes , you are correct this is a unit test , should i try to change it to a integeration test like what i can check is by sending a real network request in the login with some data i can check weather its actually changing the store as user authenticated true or not and then check weather the user was redirected or not , and can also check by sending invalid credentials and can check that it doesnt change the state in store , does this way sounds correct?? or should i just keep it as it as and rename it to a unit test

I would say just renaming is sufficient. I believe the behaviour you're describing is covered in the e2e tests @Geethegreat could you confirm?
Renamed it. Does it need any other changes?