Add Vitest snapshost test example#85
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Thank you so much for your contribution to Kuma UI. Your proposed custom serializer solution for including stylesheets in the snapshot testing is truly insightful and can help address the existing problem of the lack of diff when a style changes. I understand that the solution currently ties to the implementation of our Vite plugin, which injects CSS into the DOM during the development stage. This approach indeed solves the issue for the time being. However, I'm considering migrating to Virtual Modules in the future. With that in mind, I will have to find an approach that remains compatible after this change. I highly appreciate your pull request, and I plan to keep it open as I consider these options. Your solution serves as a great reference for us moving forward. I may seek your expertise again as I continue to evaluate and implement the best method for Kuma UI testing. Thank you once again for your invaluable input 🙏 |
Overview
Add Vitest snapshost test example.
Problem
With no configuration, CSS does not appear in snapshots and is not subject for testing.
Also, in kuma-ui, since the hash is calculated using the style string, if the style changes, only the classnames will have a diff. I think this diff lacks information and is not enough convincing for developer to approve this change.
Solution
For this reason, I have written an implementation of a custom serializer in a format very similar to @emotion/jest.
https://emotion.sh/docs/testing
As a result, the hash is assigned an index that does not depend on the description in the order of appearance, so no differences will appear in the value of the class itself. Also, since CSS is output at the beginning of the snapshot, it becomes possible to collectively verify changes in style with the component's snapshot.
Comment
The implementation of this serializer is not so strongly related to the implementation of kuma-ui itself, so I think it's not worth packaging, but I think it's no problem to have it as a reference implementation. What do you think?