add tests

[travis]

UI testing! A very special hell that we should probably brave sooner than later.

We currently have a codesandbox integration configured that at least builds the example apps in CI.

We should add tests similar to the ones in the HeadlessUI component library, eg:

https://github.com/tailwindlabs/headlessui/blob/main/packages/%40headlessui-react/src/components/combobox/combobox.test.tsx

Now that we have a bit of complexity in this library, some basic testing will probably make our lives easier down the road.

[alanshaw]

🙏 yes please, I am the worst for not adding in the first place.

[travis]

I spent a bit of time before the break on this and ran into some annoying issues where Jest had trouble loading ESM dependencies. @hugomrdias mentioned yesterday that he was interested in looking into alternatives to Jest, which I'd be excited about based on this experience and others, and spent a bit of time researching the state of the art during which I found this article:

https://whistlr.info/2022/test-react-builtin/

TLDR is

a) Node 18 comes with a builtin testing library node:test that uses ESM rather than insisting on CJS as Jest does, which should help with the issues I was having
b) node:test is definitely much more barebones than Jest or Mocha, and needs some sugar to feel as slick as Jest or Mocha
c) because node:test uses ESM, mocking third party dependencies is hard:

Given all this I'm leaning slightly in the direction of trying to use node:test but probably need to discuss further with anyone interested. Would love to know what others think/if anyone has experience with this stuff and can provide an informed perspective!

[gobengo]

@travis in general I've been told (by @alanshaw iirc) that we should use ava for tests. It's a good middle ground that supports ESM.

I did some tinkering over break with node:test builtin. It's ok but IMO doesn't have as good a story around --watch or reporters as ava does.

[travis]

this has been broken down into #222 and #223. keeping this around to track the higher level intent to add more testing but we can close it once the sub-issues are closed.

[olizilla]

here is a nice example of reusing the vite preview server for a browser based playwright test from vitest.
https://github.com/vitest-dev/vitest/blob/main/examples/playwright/test/basic.test.ts

for integration tests, i think re-using the vite preview server would be a win, and using playwright to handle browsers for us has been the least worst option we've hit so far.

playwright-test is optional... we can use it's expect implementation where it helps us. it's adapted to keep checking a condition instead of failing immediately, to deal having to wait for a separate browser process to do the thing.

vitest is a wildcard, but might be a sensible choice to replace jest. vitest would reuse our vite config, and bring our dev and test set up closer together. I should caveat that i don't love chunky, global-meddling, test framewords like jest or vitest, but there is an argument for using something that is popular for frontend projects so we can point to a good example and catch any gotchas ourselves before other users do. Also noting that jest still being cjs only and somewhat stuck there if it wants to keep mocking means it may quickly fall out of favour.

[olizilla]

We could use ava here to align with our other repos, and this example shows how we might integrate ava and playwright https://playwright.dev/docs/test-runners#ava

[olizilla]

i'm exploring plain vanilla playwright integration testing for our examples in #238

[alanshaw]

Now that #242 is merged can we consider this issue closed?

[travis]

yep I think so!