Improve automated test coverage and depth

[endigo9740]

@niktek @thomasbjespersen and I discussed this on Discord.

General idea is we now have our Vitest configuration up to date, we have tests applied to every existing component, and we've improved the quality of these. However, we need to go a bit further to ensure we have an adequate number of quality of test cases per component. This will make it easier to introduce new features, handle refactors, and of course improve general QA testing.

@niktek has volunteered to aid with this, so please claim the ticket when you can sir! I can provide an in-depth overview of how the tests are implemented and working.

Notable changes may include:

• Ensure every component includes at least some rudimentary tests.
• Help update the Contributor guide to provide our requirements for testing newly introduced components
• Let's review what currently available test cases are providing value, and which are not

With the ultimate goal of ensuring we have a set of simple and robust test cases that are not too rigid. Some component design and features are still in flux, so tests that are too strict may not be helpful.

[endigo9740]

@niktek Still interested in taking this on? If so leave a comment here and I can assign to you.

[endigo9740]

https:/davipon/svelte-component-test-recipes

[amjadorfali]

I have a fair share of experience in handling test cases for Unit/Integration/component testings using React-testing-library, and even testing the component lifecycle methods (hooks)

Although i have never written a single test using Vitest, i can't imagine it would be that hard.

Given that, i'd be happy to take on this task, although i will take some time with it due to my full-time job. But honestly i would love to do it, because 1 : I love Skeleton.dev, i think the work you guys are putting here is truly awesome <3 And 2 : I love svelte, and been tinkering around with it and building up my personal portfolio using it (amjadorfali.com)

Please let me know your thoughts on this, where should i start etc...

@endigo9740

[endigo9740]

@amjadorfali In this case this is probably a ticket that should be broke up and shared by several individuals, rather than a one and done. I shared my thoughts on the subject in this recorded call with a couple other contributors. It's an hour long so feel free to skim if you're short on time:
https://www.youtube.com/watch?v=Ru3FtSzN128&feature=youtu.be

But general idea is there's several parts to this:

1. We need to add tests to features that don't yet have them (ex: input chips)
2. We need to improve the tests that do exist, many are using outdated props. The tests pass, but their inaccurate to real world scenarios
3. We need to greatly improve the quality of the tests (a lot of what the video above covers)

Being able to write good unit and integration tests requires a strong understanding of how the features operate, so I might suggest you start there. Then, when you're ready submit a PR for a SINGLE test. We can use that as our proof of concept to establish the expectations for the quality of the tests. I'd suggest one for any of the newer slew of features that are missing tests outright.

[amjadorfali]

@endigo9740 Awesome! Sounds great, will be diving deep into this during the weekend

[amjadorfali]

I marked the PR as a Draft as mentioned in the contributions guidelines. As i'm fairly new to open-source contributions, I don't know if you will get notified about this PR (Maybe cause I linked it to the issue?)
So I'm mentioning you here just in case 😅 @endigo9740

[endigo9740]

@amjadorfali I did get notified, but thanks for the heads up. I see there's a good number so changes so I'll need to circle back when I have more bandwidth. Feel free to refine the test as is in the meantime and I'll provide feedback on the PR as to any particular changes needed. Thanks!

[amjadorfali]

@endigo9740 Awesome, sounds good. I have certain refinements in mind but they require adding/setting up additional libraries. Should I address that or wait for confirmation ?

[endigo9740]

We do not implement new project dependencies without due diligence first and almost never from first time contributors. I'd recommend noting what you would like to include in the PR thread and I can research those as part of the PR audit.

Just FYI it may take a while for me to get to this audit. Our priorities are strictly on the documentation focus ticket and updates pinned at the top of our Issue tracker right now. Thanks for your patience in the meantime

[amjadorfali]

Hey @endigo9740 , hope all's well.

I wanted to checkup on this issue, I'm happy to help with any testing approach that's acceptable for this library. I just want to contribute to this library, as it already helped me so much with my website, and it amazes me every time i read the docs and learn more and more about it. So I'd love to give back by any means necessary. I'll write all the tests for the library if needed, Unit, Integration, E2E, visual regression ... i just wanna contribute 😅

Thanks again! 🥂

[endigo9740]

No further updates from here unfortunately:
#1029 (comment)

Right now my focus is on several new initiatives for Skeleton Labs. One of which will be announced as part of tomorrow's release. So maybe keep an eye out for that. Long story short, we're quite busy behind the scenes, even if it's not visible on GitHub at the moment.

[endigo9740]

In an effort to prepare for Skeleton v3, we're consolidate some related issues down to a single ticket. This will ensure that we can see the full context of requests when the time comes to refactor and update this feature going forward. If you wish to add additional feedback or suggestions, please so here:

• NEXT: Automated Testing #2363