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

tests: add tests for some components #12108

Merged
merged 10 commits into from
May 3, 2024
Merged

Conversation

EshaanAgg
Copy link
Contributor

Summary

Introduced a test suite for the following components:

  • UserTypeDisplay.vue
  • FocusTrap.vue
  • TimeDuration.vue

References

Reviewer guidance


Testing checklist

  • Contributor has fully tested the PR manually
  • If there are any front-end changes, before/after screenshots are included
  • Critical user journeys are covered by Gherkin stories
  • Critical and brittle code paths are covered by unit tests

PR process

  • PR has the correct target branch and milestone
  • PR has 'needs review' or 'work-in-progress' label
  • If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
  • If this is an important user-facing change, PR or related issue has a 'changelog' label
  • If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

  • Automated test coverage is satisfactory
  • PR is fully functional
  • PR has been tested for accessibility regressions
  • External dependency files were updated if necessary (yarn and pip)
  • Documentation is updated
  • Contributor is in AUTHORS.md

@@ -1,7 +1,7 @@
<template>

<KOptionalText
:text="seconds ? formattedTime : ''"
:text="seconds !== null ? formattedTime : ''"
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Made this change as earlier passing 0 as seconds led to this expression being evaluated as false, and thus an empty string being displayed instead of 0 seconds. Also added a test case related to the same.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not very sure if the way I have chosen is the most user-centric way to test this FocusTrap component. Would appreciate any feedback on the same.

Copy link
Member

@nucleogenesis nucleogenesis 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 this - the tests are great and seem to cover everything very well.

I made a couple of notes / suggestions, but they're not blocking for merge.

import VueRouter from 'vue-router';
import FocusTrap from '../FocusTrap.vue';

const renderComponent = (props = {}) => {
Copy link
Member

Choose a reason for hiding this comment

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

The FocusTrap tests look good.

Not a blocker -- the only thing I could think that might be worth adding is a call to the public reset method on FocusTrap to see that it updates isTrapActive and such.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it! That's an important use case. Will add tests for it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added a test suite to cover this use-case, but I can't get it to work. Like to access the public method reset of the component, we would need to add a wrapper around it so that the user can access the same. I tried writing a test suite with the same, but can't get it to work. Would highly appreciate any help with the same.

Copy link
Member

Choose a reason for hiding this comment

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

I think this is a case where the 'user' of the component is actually the developer, so I don't think it's necessary to do this via DOM interaction, and the reset method can be invoked programmatically - as it forms part of the public API of the component.

Copy link
Member

@AlexVelezLl AlexVelezLl left a comment

Choose a reason for hiding this comment

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

Thanks @EshaanAgg! I just left two little comments but are non-blocking, just to reflect a little on the functionality we are testing, but everything else looks good to me! 👐.

Copy link
Member

@rtibbles rtibbles left a comment

Choose a reason for hiding this comment

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

As @nucleogenesis didn't flag this as a blocker, I think we should just remove the reset method testing here, both the wrapper component for testing, and the test in the spec file itself.

Doing this will also fix the extant linting issues, so I think it's a win-win.

Signed-off-by: Eshaan Aggarwal <96648934+EshaanAgg@users.noreply.github.com>
@EshaanAgg
Copy link
Contributor Author

Got it @rtibbles! Thanks for the review. I have updated to remove the reset test.

@rtibbles
Copy link
Member

rtibbles commented May 3, 2024

Thank you @EshaanAgg - you responded so fast I was genuinely surprised!

@EshaanAgg
Copy link
Contributor Author

😂
I have an exam tomorrow, and the last paper syndrome has got me active on everything other than preparing for the same :) Thanks for the help on the PR!

@rtibbles
Copy link
Member

rtibbles commented May 3, 2024

Many things have been achieved by students trying to avoid what they are meant to be working on!

@rtibbles rtibbles merged commit aabce4d into learningequality:develop May 3, 2024
31 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants