LOOKING FOR CONTRIBUTIONS
I would really value your input if you can help me improve this test suite. Please see below for a brief explanation of what I'm after.
This is a work-in-progress test suite example for web components.
It arose because I wanted to have the same expectations with testing as I do with any other frontend stack as I do when building Web Components.
I also found that the existing tutorials and libraries for this purpose use frameworks like Lit. Whilst I see the value in those frameworks, personally I just ditched my abstractions and I don't want to adopt another. I want to build with native web tools.
I've used media-chrome as a basis for this test suite because it's a non-trivial Web Component. It's also a really well thought out project which I enjoy using.
This repo contains my tools of choice for the following:
- Static analysis: JSDoc
- Unit testing: Vitest
- E2E testing: Cypress
- Manual testing: Storybook
- Bundling: Vite
I have leveraged additional tools from FicusJS, which is another abstraction to web components, but I've used it solely in my testing cycle to provide me with extra functionality to JSDOM that is suited to rendering web components.
Each of these currently have limitations when it comes to testing web components, and I really hope it doesn't stay that way.
These limitations are listed below:
- Static typing functions and variables
- Typing arguments in a HTML Element unless they are explicitly declared
Storybook has the most support for web components.
- Render a component
- Alter Rendered component based on arguments
- Fire events to the component
- Observe events bubbled from the component
- Checking whether an item in the internal ui has rendered as a result of arguments passed
- Observing events inside the component
- Render a component
- Alter Rendered component based on arguments
- Fire events to the component
- Observe events bubbled from the component
- Checking whether an item in the internal ui has rendered as a result of arguments passed
- Observing events inside the component
- Render a component
- Alter Rendered component based on arguments
- Fire events to the component
- Observe events bubbled from the component
- Checking whether an item in the internal ui has rendered as a result of arguments passed
- [not checked] Observing events inside the component
- Render a component
- Alter Rendered component based on arguments
- Fire events to the component
- Observe events bubbled from the component
- Checking whether an item in the internal ui has rendered as a result of arguments passed
- Observing events inside the component
Works fine with web components.
I'm pretty new to this web components thing, and would love it if someone could educate me where I've gone wrong with each of these.
I don't mind anything I don't yet know about that improves the test coverage for any of these tools. This would include alternative DOM libraries and other tools, However my one requirement is that it does not extensively use abstractions from web components to do so.
For example, I know I can likely get better test coverage if I use Lit Element instead of the barebones HTML Element. But my requirement is that I want to use an HTML Element.
If you're going to suggest a change to this readme, please also provide code examples in the pull request by adding to the existing test suites.