Needs tests

[benwiley4000]

We could use some component tests, as the API has become a bit complex to validate changes just by loading example.html in a web browser.

[benwiley4000]

If you're here from Hacktoberfest you can also help out by adding documentation! 😃

[benwiley4000]

@danielr18 I've push a branch called in-progress-test-setup. I worked on it a few nights ago. It has a small example snapshot test and jest configuration. However it seems like the JSX transform isn't working. Not sure what I did wrong, and I was too tired to spend more time on it. I can look again sometime but if you have any idea and want to help out, that would be appreciated. :) If not, I'll get to it eventually.

If you want to check it out locally you'll need to run:

git checkout in-progress-test-setup
$(npm bin)/lerna bootstrap # installs all the test dependencies
npm test

[danielr18]

I think it's because babel.config.js support was added on babel 7 beta 46, and we are currently at 41. I'll update babel 7 packages and push the changes if I get JSX working.

[benwiley4000]

Ah!! You're probably right, I forgot I was still on an old beta version.

[benwiley4000]

Jest stuff is now merged into the next branch. I've added one passing snapshot test for now, as a starting point. Obviously we want more coverage. :) I'll leave this issue open until we get there.

[benwiley4000]

This comment was originally posted here but makes more sense in the general testing issue:

---

I think Jest is a good tool to use. I could use some help brainstorming, but here's a starter checklist:

Component snapshot tests

@cassette/player

Each of these should be wrapped in context providers with mock values (the actual Context.Provider, not the smart wrapper):

• [ ] MediaPlayerControls
• [ ] All the control components
• Stuff that might be hard to test:
  • VolumeControl - can we mock different internal states?

    @cassette/components

• [ ] ProgressBarDisplay
• [ ] Maybe ProgressBar (just to mock the adjusting state?)
• [ ] MaybeMarquee
• [ ] VideoDisplay
• Stuff that might be hard to test:
  • Potentially everything except for ProgressBarDisplay? These might be lower priority, especially since they're each so dependent on the DOM and on internal states.

    Unit tests for util functions

    The various separated util functions could all have tests, and perhaps new util functions could be pulled out

    Context tests

    It might require some refactoring and some mocks e.g. of the HTMLVideoElement, but it would be good to have API tests for the playerContext and fullscreenContext. I'm imagining that for the majority of functions available through the context, we have a test or tests that call the function then check afterward that:

    1. The expected update occurred in the mock HTMLVideoElement
    2. The expected change occurred in the context Many of these updates will be asynchronous and some might even not be done on the next tick, so coding this could be tricky.

Mocking stuff from the browser will be an issue to resolve.

[benwiley4000]

These tests don't need to be done before the beta release is out. They can be part of the beta stabilization phase.