search

flackr / scroll-timeline

A polyfill of ScrollTimeline.
Apache License 2.0
885 stars 82 forks source link

Add test framework for unit tests #207

Open johannesodland opened 5 months ago

johannesodland commented 5 months ago

Could we add a test framework for unit tests?

It would be useful to be able to build unit tests for some of the functionality. The web platform tests can take quite a while to run, and it would be useful to add unit tests where we implement internal procedures that are not tested directly in the WPT tests.

bramus commented 5 months ago

Yes, this is more than reasonable to do.

Which test suite did you have in mind? In the past I’ve used mocha which was very easy to work with but if I’m not mistaken Node comes with a testrunner nowadays.

flackr commented 5 months ago

I'm interested in switching the build system as well, and possibly using typescript so that there'd be better IDE integration, documentation of types, etc. I was thinking maybe vite? In which case vitest..?

flackr commented 5 months ago

I want a build system that will make it easy to set up at least three different versions of the build,

  1. A full minified version much like the one produced today.
  2. A light minified version which doesn't include the CSS parsing, or processing heavy observers, for use in cases where authors know that their animations are static once set up.
  3. A debug version with no minification to make it easier to understand and debug errors in dev tools - possibly also forcing the use of the polyfill to allow for testing even in chrome where SDA is supported - though it would not be foolproof.
flackr commented 5 months ago

add unit tests where we implement internal procedures

I suspect it would be good to avoid testing parts that are not publicly observable, as otherwise it might create unnecessary work when improving the internals. But there are many things not tested in wpt, that possibly don't make sense to test in wpt but would make sense to test, e.g. that the css parsing correctly respects @media queries, nested selectors, etc, where in wpt it is assumed that the features work together because they're independent from one another in browser space.

johannesodland commented 5 months ago

I was thinking maybe vite? In which case vitest..?

I haven't tested Vite in library mode, but it sounds tempting. Vitest works great, I've used it for testing some of the features before committing a PR. (I also tried Jest, but it doesn't work well with esm.)

I suspect it would be good to avoid testing parts that are not publicly observable, as otherwise it might create unnecessary work when improving the internals.

I agree. I think testing the internal implementations through the public API would be best.