tests: add tests for some files in ContentRenderer

[EshaanAgg]

Summary

• Added the tests for the components as well as utility JavaScript file in the ContentRenderer directory
• The tests for the ContentRenderer/DownloadButton are not complete, as even when I pass valid files to the same, I can't see a dropdown being rendered in the DOM, and thus I am unable to test its user interaction. Would highly appreciate any help I can get on the same.

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

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-.pex
Windows Installer (EXE)	kolibri-0.16.1.dev0+git.20240418143140-unsigned.exe
Debian Package	kolibri_0.16.1.dev0+git.20240418143140-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.16.1.dev0+git.20240418143140-0.4.0.dmg
Android Package (APK)	kolibri-0.16.1.dev0+git.20240418143140-0.1.0-debug.apk
TAR file	kolibri-0.16.1.dev0+git.20240418143140.tar.gz
WHL file	kolibri-0.16.1.dev0+git.20240418143140-py2.py3-none-any.whl

[rtibbles]

I am not sure - but I suspect that you are mocking isAppContext incorrectly. It is coming from the useUser composable: https://github.com/learningequality/kolibri/blob/develop/kolibri/core/assets/src/views/ContentRenderer/DownloadButton.vue#L30 not from Vuex, so should be mocked using jest.mock('kolibri.coreVue.composables.useUser'); in your test file. For more details look at the useUser mock in the codebase on how to simulate specific values also.

[EshaanAgg]

My bad @rtibbles! Since the composable itself operates on a Vuex store, I though it would be better to mock the store directly. But I see the merit in mocking the composable directly in terms of the clarity and ease. Thanks for the feedback. I will update the same.

[akolson]

Thanks @EshaanAgg! The tests look correct to me. Furthermore, the isAppContext seems to be mocked correctly now.

[AlexVelezLl]

Hi @EshaanAgg! Thank you! This is looking fine! Just a couple of comments on some test names, and reminders that we dont need to include the import '@testing-library/jest-dom'; statement on every test suite 👐.

[AlexVelezLl]

I think we need to find a better way of passing the useUserMock values, because reading just the testcase I could think that isAppContextis a prop of the component, but it isn't, so we can maybe wrap this value in a useUserMock object? This way the name suggest that we are passing this value to a mock of a composable. And we can end up in something like:

renderComponent({
  files: [],
  useUserMock: { isAppContext: false }
});

Let me know what do you think, as we can standarize this way of passing composables mock values.

[EshaanAgg]

Indeed, this looks better! This provides a clear boundary between the props of the component, and all the other configuration that might be required by it, making it easier to reason about. Will update!

[AlexVelezLl]

Just flagging that we are still passing the isAppContext as prop here. To prevent this from happening, we can use destructuring:

const renderComponent = props => {
  const { isAppContext, ...componentProps } = props;
  ...
}; 

[EshaanAgg]

Got it! Since how we are using the name useUserMock for all the composable mocks, the structure would be a bit different, but I get the spirit. Thanks!

[AlexVelezLl]

Thanks @EshaanAgg! This looks great! LGTM.