Video není dostupné.
Omlouváme se.
🧪 Test SvelteKit with TDD & VITEST 🧪
Vložit
- čas přidán 28. 07. 2024
- Let’s use Test-Driven Development and test our SvelteKit app with VITEST! Blazing-fast tests, to go with our blazing-fast bundler 🚀
Do not be alarmed by the length of the video, the initial setup is relatively quick!
... But we go through edge-cases, common problems and hot tips, and we finish with an extended “coding & chill” session to complete our spec and freshen-up our design 💅 Feel free to use the timestamps / chapters to jump around!
If you’ve never heard of TDD, Test-Driven Development, before, we go through how I’d TDD a real-life problem! Maybe use that section as inspiration for your next coding challenge? 😄
See the code: github.com/jmagrippis/vitest-...
See the deployed Dashboard: vitest-with-sveltekit.vercel....
Highlighted software:
SvelteKit: kit.svelte.dev/
Vitest: vitest.dev/
Playwright: playwright.dev/
🎶 I’ve remixed “Eye Candy”, “Soft Peach” & “Hank’s Acid Trip” by Sven Lindvall & Daniel Fridell for the background music 🎶
No affiliations whatsoever: if I show something, you know you're hearing my unfiltered thoughts 😄
My own website: magrippis.com/
Search for @jmagrippis to find me on socials like Instagram and Twitter!
Between the comment section and the socials, let me know somewhere what you’d like me to cover next 🙌
--
TIMESTAMPS
--
0:00 - Why VITEST with SvelteKit over Jest?
1:11 - Vanilla Setup and TDD-ing a Unit Test 🧪
3:02 - Why hard-code solutions? 🔴🟢♻️
3:53 - Setup for SvelteKit & testing Components
5:46 - vitest-svelte-kit to the rescue
6:35 - Setting up svelte-testing-library
7:15 - The need for a browser environment like jsdom
7:39 - Where to pass Vitest config options?
8:15 - Prove it all works, with some Fake TDD 😄
8:47 - Jest-style globals & extended expect matchers
10:03 - Vitest VSCode plugin
10:24 - Cannot find base tsconfig.json? How to fix CI
12:10 - When to Vitest, when to Playwright / Cypress?
13:03 - TDD & chill to finish our spec! ✅
18:13 - Design & chill to finish our video! 💅
22:41 - Next steps + Comment & Subscribe 🧡
Hey everyone! I've tried something new for this video, it's about 1/3 "essential setup", then 1/3 "common tweaks, gotchas & bonus tips", and a final third of "coding & chill" 😎
Let me know if you enjoy that composition, or if you'd rather I just talk all the time, or focus on the most common problems, or if you do like just seeing me code a bit, or whatever feedback you have! 😄
It seems that the vitest-svelte-kit is obsoleted. Tried to setup from init new SvelteKit KitQL project with Houdini and Vite, definitely really hard to configure so that even simplest Svelte modules can be tested.
The problem is that Vitest doesn't manage SvelteKit $app module paths properly... and pretty extensive searching for working configuration haven't helped yet.
Any pointers to right direction?
@@mhelander yes, ever since Svelte changed how it works with Vite, you don’t need the extra plug-in, and the SvelteKit wizard can also set Vitest up for you out of the box! I hope the rest of the video is still useful to people 😅
As to the path aliases, things like $app and $env and even $lib, they have worked for me across various versions! They should, given if Vite & the dev server can resolve them, so should Vitest… Are you using Typescript as well? Do you have the dev server running, along with the tests?
@@jmagrippis big thanks for your video, despite my problems. I'll try again with a fresh create project...
Btw my experiences are with merger of the create project and working KitQL project HoudiniQL example-sveltekit-todo, it didn't play properly with vitest and playwright.
I'm in progress to figure out best combination of the tools for new project and driving it towards TDD, former for more unit testing as you've focused on this video and latter for functional testing of bigger chunks
Thank you you explained very well. This is my first video of unit-testing, vitest, and TDD and you covered it very well. Practical and concise. Please do more videos!
Thank you so much Khairul, that's so exciting! I hope your testing journey has been going well 😄
I slowly am getting back into videos (and definitely streams!), so do let me know if there's something in particular you don't see having much coverage, or you'd like to see me try to explain! 🙌
Awesome! Exactly what I needed. Thanks for the great work!
Amazing, I always say if at least one person finds what they need from these videos, it's worth it, so many thanks for letting me know 😄
I love you, thank you so much!! And I absolutely love the style of the video, very pleasant and helpful!
Thanks! I’ll keep tweaking the style trying to improve, but I know they’ll always be pleasant: I love tech & enjoy getting these videos out there 😄
Unbelievable, this is a most helpful video I have ever watch regarding SvelteKit. Totally love it.Thank you so much.
Wow, what a compliment, such high praise 🙌 thank you so much, and please do let me know if there's something in particular you'd like to see me cover in the future 🙂
Damn, this channel is actually on point. Nice editing, clear and good explanations & great content!!!
Also the "chill" section is very valuable when put just before a great tutorial you've just delivered. It helps giving practical context, which is very important.
Way to go Johnny!!
Such high praise, thank you so much Luca!
I've started doing the "opposite" chill sessions in livestreams too, where I've got a rough idea of what I wanna figure out (after polling the community!), and I spend the hours live trying to figure it out! Which may lead to me shooting a "distilled" video, which may have a "chill" section where I implement more slowly... but still quite fast given at that point I know what I wanna do 😄
Thanks again, and let me know if you've got particular subjects you'd like me to hit!
@@venir_dev That's great, I'm always looking for excuses to check out Vue / Nuxt!
I do a little project every year, but it hasn't really clicked with me so far... I do find it much better than the early days, where I thought Vue was the parts from Angular + the parts of React I liked *least*, I think the tooling is awesome, there are lots of first-class video tutorials... But I think it's the... variety of opinions & options that holds it back for me! Which is very interesting versus your preference 😄
I remember on my last attempt, I looked around, decided I do want to go the new Vue 3 way of defining components... and then found the then current version of Nuxt didn't support Vue 3 yet (╯°□°)╯︵ ┻━┻
But I'm always excited to give it a go, that's how the great ideas get "pollinated" across frameworks after all 😄
i18n & localisation has been on my ideas board for a while! I may give it a go next stream...
I've mentioned it as "the one remaining thing" that can make going with SvelteKit a worse choice. You can work and hack around it, but Next.js (and I imagine Nuxt?) gives you such a head start to a proper first-class solution, you'd be handicapping yourself by not choosing them, if it is important to the app you're building.
--
Vitest with Nuxt is also a good suggestion! Given I'm a Nuxt beginner, it'd be fun to take this angle, and maybe see if I can TDD an app / a few components from a fresh install!
Subscribed. This is the clearest description and tutorial I've ever seen on testing svelte and sveltekit. I can't believe this isn't part of the main svelte documentation.
Thanks Kaibe! Keep in mind things have changed since this video: for example, SvelteKit now integrates with the Vite config in a more sensible way, so you don’t need ‘vitest-svelte-kit’ anymore! The sveltekit wizard with ‘npm create svelte@latest’ can now set you up with Vitest out of the box 🚀
But I expected this 😅 and know the Svelte team takes videos and feedback into account to keep improving, so in my head it’s always worth to walk through these things in public 😄 and did try to include general advice that I hope is useful today to get people started with Vitest, or even TDD in different frameworks!
Thanks again for the sub and most of all for watching and the kind words 🙌
@@jmagrippis That may be the case, but they still don't have docs on how to test svelte components.etc. It's a massive oversight, especially now we're in version 3, and doubly so considering how important tests and TDD are to modern development.
In stark contrast, vue has had, since version 1, clear instructions on how to test vue and its components.
That’s true! Vue has never really “clicked” with me but I’ve always been impressed and inspired by its tools, docs & community. Dev Ex in those aspects feels like a cut above!
Covering TDD / BDD more thoroughly is especially important for SvelteKit, because it does do quite a lot of “SvelteKit magic” with its meta framework nature… It’s easy to get lost regarding what runs on the server, what on the client, what may run on both, what gives data to what…
I keep trying to “script” a video like “When to Vitest & when to Playwright: Do I need both?!” but we’ll see if I ever manage it 😅
@@jmagrippis Do you have any idea how to use env vars in tests? (sourced from dotenv files). Am trying to test a store, which relies on env vars, again no clear tuts or anything on the web that I can find lol
Whoops, I missed this!
One way to do it is to using Vitest's `globalSetup` option, pointing to a file which uses `dotenv` or `dotenv-flow`, which would be importing your `.env.test`.
I made an example for this now, just for you 😄
github.com/jmagrippis/johnnify/blob/main/vite.config.ts#L27
github.com/jmagrippis/johnnify/blob/main/src/vitestSetup.ts#L4
But also because it's a good idea to show an approach for solving this, since as you say there aren't any obvious tutorials / fruitful google searches!
Let me know if you did end up with a similar or different solution in the meantime! 🙂
Thank you Johnny ! I really like your style and the content of your video (and your spanish accent !)
Haha, 99% of people were guessing I'm from Spain even when I lived in London, so I can imagine it will go to a perfect 100% now that I'm in Barcelona 😄
But I'm actually from a little Greek island! 🤯
Thank you for your lovely comment, and let me know your ideas for subjects you'd like me to cover!
Great video Johnny! The coding and chill section was well…very chilled ❤️
Yay, glad you thought so 🙌 I'm finally setting up a livestream for tomorrow, I'm hoping it'll go mostly like that! Maybe with a bit more talking and quite a few more typos 😄
@@jmagrippis Great! Will that be on here or Twitch?
I'll try to make CZcams Live work, as I hope some will be useful / workable enough to keep them around in Playlists here! So people won't have to juggle through platforms to binge-watch some app dev thoughts and coding by me 😄
Amazing content Johnny! Chill part is golden!
Thanks for watching Samuel, and for the feedback 😄
Awesome video mate! Thanks slot.
Hey, thank *you* for watching 🙌 and let me know if you've got subjects you'd like to see me cover 😄
Wow. I'm really impressed. Amazing content. I was struggling how to configure Vite with Sveltekit, thanks for this video. New subscriber. Glad to see such a talented programmer in the svelte community. Psdt. Quick Question: Any thoughts, opinions or any experience of working with svelte & wasm (with rust for example)?
Hello Bryan! Thanks for the sub and the super flattering comment! I don't think my programming talents are as rare as you make it sound, in any community 😅 Maybe a talent for combining tools other talented people have created, and sometimes typing & autocompleting quickly 😛
I haven't tried Web Assembly for anything I'm afraid! So my "looking from the outside" thoughts are...
I haven't come across something where my stack (Javascript / Typescript) is the bottleneck when it comes to perceptible performance for the user. I have come across things that "just work better if we did them in language X", namely Python (ML & data stuff) or even Clojure (streaming with Kafka), but then we could have that integration / service in that language and expose an API we hit with from our Typescript.
So for the stuff I'm working with, I see the big WASM advantage to be "fullstack in one language!"... but for me that language would be Typescript, which I know better and I find easier to hire for 😄 So I'd rather have a SvelteKit or Next.js project and ship that! Maybe I'd feel different if I was a Rust pro and really wanted most of my code to be in that! Or I had a team of Rust pros that were intimidated by the frontend? (But then again, I'd suspect it'd be easier to teach them Next.js / SvelteKit than figure out WASM on the fly, and without clear "this is how you should do it!" example leaders!)
Saying that, if I were proficient in Swift, it'd be awesome to have truly native Mac & iOS apps, and then have a magic WASM solution to ship that to the web too... Should be better than your average Electron app? Or React Native / Svelte Native... Hm...
--
Again, that's my "looking from the outside" views, as someone who does "simpler" app dev! What are your thoughts, why have you been looking into it? 🙂 Am I way off on what Web Assembly could give me at the moment?
Brilliant, ty so much!!!
Great video, easy to follow and just the right level of detail!
Thanks for this comment Laurie, and for subscribing! 😄
Let me know if you've got particular subjects in mind, on what you may want me to cover in the future 🙂
@@jmagrippis How about doing something with Threlte, the Svelte + Three.js library for 3D? It's not super well known but has some really nice features.
@@laurieinjapan Oh cool! I did try out Svelte Cubed back in the day, but haven't kept up to date, and didn't know about Threlte! Apparently even Rich says "it's where it's at" 🙂
I know lots of devs do amazing stuff with Three, so I'm always on the lookout to make it more accessible via other frameworks... I'll be having a look for sure, great suggestion! Thanks 🙌
I love your channel and SvelteKit Videos, thank you for putting so much effort into high quality content!
I understand SvelteKit recently released a change to seperate the Vite config from the svelte config. In this case would it just allow us to skip the extra dependency that extracts the config? I'm keen to try this out in my project.
Oh! I just saw that you already addressed this in the Playwright stream, thanks.
Hey Spikey! Thanks for watching even the livestreams!
Yes, I did say that on the stream, and your first comment reminded me I should probably validate that 😂
So, I just migrated the with-svelte app to use the latest libraries, and can confirm it is indeed true! Which means we may actually "zero-config" test SvelteKit apps with Vitest, which is awesome! No need for the extra library, Vitest will read the `vite.config.js` automatically, which will have all the sveltekit magic configured for us.
So that section of the video is now obsolete, but hopefully my surrounding words remain helpful 😄
Hope you have lots of fun with your project!
Great video man.. helped me a ton learning vitest. I'm new to vitest scene and couldn't figure out how to do accessibility unit testing of components.. may be an idea for your next video 🤷
Hey, thanks for watching and commenting! I always love learning people find my videos useful, especially when it comes to testing & TDD 😄
Great suggestion as well! The SvelteKit wizard can set you up with an eslint config that will highlight some basic accessibility violations in your components, and I've been looking into github.com/chaance/vitest-axe, which integrates the axe accessibility linter with Vitest. I've used the axe linter in quite a few projects either by itself, or through other tools that use it behind the scenes and it's decent!
I'd usually add it to an "actual browser" test runner like Playwright, but I can see the appeal of wanting to configure Vitest with it, it's just sooooo fast and handy for quick development.
--
Will look into it more and see if I can draft a video about the subject, but wanted to give some early thoughts in the meantime 😄 Thanks again Lopsang!
@@jmagrippis Thanks for the reply Johnny.. I've use jest-axe before and was something similar to that, the package you've suggested.. I'll look into it.. but hope you make a video on this topic as well 🤞
Hi! There is a way to test the navigation using vitest in Sveltekit? Meaning that when a click on a anchor tag, checks if it takes me to the expected page.
Great Job!
Woohoo, thanks for watching 😄
Thank you!
My pleasure, thanks for watching 😄
Hi! Very cool video! One question, how would you test components that support slots?
Hey thanks!
That's a great question! Unfortunately you can't test like you would in React for example, by "just rendering" the components with JSX and putting in the slots you wanna use. There is this discussion in the svelte-testing-library repo I'm watching, with a couple of workarounds: github.com/testing-library/svelte-testing-library/issues/48
My practical workaround for testing slots is to test a level higher. So if we have the CurrencyStat component that takes a slot for its icon, we'd test on the Dashboard level which uses a few CurrencyStat components in it. We could `getByTitle` to assert we've got all the SVG icons we expect.
Also, this has made me sometimes favour using a prop instead of a slot! So if we have CurrencyStat take a prop for its `label`, and always render the label content in an h3, that's more easily unit-testable. Because we could have allowed for a ` and then we can pass in an h2, h4, just a div, whatever we wish the label to be... but then we'd have to resort to testing that functionality through a component higher up, or with `svelte-inline-component` mentioned in that discussion, which is more hard-to-read boilerplate!
It's generally a bad idea to write code in the implementation specifically for the tests, but I see this more of a case on making a *simpler* component which is more easily testable, so preferable so long as we ain't really compromising our functionality! 😬
@@jmagrippisThank you for that reply, very interesting and complete response. I'm currently developing a ui library, so slots are kinda vital for some parts, not really interchangable with props. I've tried some workarounds but not really a clean solution, which is a shame. I'll also follow that discussion in the testing library, thank you for the link!
Thank you again!
Great content! Thanks!! But I have a question. I can't mock the session object of "$app/stores". I use it on various components with Sveltekit. Any idea how to do this? As a suggestion for future topics, a video on mocks with Vitest would be great, since I have seen in the documentation that there are several methods, but they are not clear to me. Thanks again!
Hey Mario! Thanks for watching, and this great question!
Personally, I avoid `vi.mock` (and other `jest.mock`-equivalents) when I can; I do like more "integration-y" tests so this does sound like a thing I'd test with Playwright / Cypress...
*However*, I dislike answers that go like "well how about you DIDN'T do the thing you want to do" 😛, so... Have you tried importing the session store from "$app/stores" normally *in the test*, and setting it to the value you want before you render the component?
Something like:
```
import { session } from '$app/stores'
import SomeComponent from './SomeComponent.svelte'
it('shows an avatar when the User is logged in', () => {
session.set({ user: { avatarUrl: 'example.com/image.png' } })
const { getByLabelText } = render(SomeComponent)
// ...
```
I haven't tried this, but maybe it would work? And even though we aren't mocking the session store, I think it would accomplish your goal of testing the components that use it in isolation, under specific scenarios! ... If it actually works 😄 So let me know if you do try this!
great video, helped me a lot
Cheers, it's my pleasure to help 😄
22:03 What is the purpose of adding `?component` when importing the SVG file?
Hey Ryan! You can specify to Vite (and Webpack & other bundlers) how you want an asset to be imported an asset using ‘?something-else’, according to how you’ve set Vite up, what other plugins you’ve got.
Most common one would be ‘?raw’, when you just want the string contents of a file, and not to parse it to a component, or to markdown or whatever.
As far as I remember from the video, the plug-in for SVG imports I was using did default to “component” even without specifying it, but needed the suffix for Typescript to figure out what was happening. I think the type definitions work better nowadays, so I don’t think I’ve needed it in more recent repos!
So if you find everything works for you, don’t worry about it, but if there’s something failing try adding that suffix 🙂
Thanks so much for watching, let me know if this cleared anything up 😄
Thanks for this video! For some reason the extension of the expect module does not work and I am getting "Property 'toBeInTheDocument' does not exist on type 'Assertion" do you have any idea why?
Thanks for watching!
Is it a Typescript type error, or a "real" error that gets thrown? If it's Typescript-only, you may need to extend the matchers as seen here: vitest.dev/guide/extending-matchers#extending-matchers
However, it's been a while since this video! If you look at step 4 of this setup page, Testing Library now recommends importing `vitest-dom/extend-expect`: testing-library.com/docs/svelte-testing-library/setup
So, around 9:12 in the video, instead of bringing in `@testing-library/jest-dom`, try `npm i -D vitest-dom`. Then, in `setupTests.ts`, `import 'vitest-dom/extend-expect'` instead of `@testing-library/jest-dom/extend-expect`.
Hopefully this will make things "just work" for you, but please let me know 🙂
This is great content, you got a new subscriber.
Woohoo, thanks Danny! Let me know if you’ve got suggestions on subjects you’d like me to cover 🙂
vitest-svelte-kit is now deprecated. How do we fix the document is not defined error?
Hey there Misty! Yeah, vitest-svelte-kit is not needed anymore because SvelteKit changed the way it hooks up with Vite, so now you can "just" use Vitest by itself and it will work.
For your problem, it sounds like you need to bring in one of the browser environments, so either `jsdom` or `happy-dom`. You need to install that dev dependency, and then in your Vite config, you put it in the `test.environment` property. So you may have a `vite.config.js` that looks like:
```
import {sveltekit} from '@sveltejs/kit/vite'
import {defineConfig} from 'vitest/config'
export default defineConfig({
plugins: [sveltekit()],
test: {
include: ['src/**/*.{test,spec}.{js,ts}'],
environment: 'happy-dom'
},
})
```
You may also specify the test environment per file, so if you've only got a few tests for stuff supposed to run in the browser (like svelte components), you could add a comment like:
// @vitest-environment jsdom
in them.
`document` should be defined with either of those options!
Hi Johnny! Is Playwright preferred over Cypress for sveltekit apps? If so, why is that? Thanks!
Hey widjaja101594 (if that's your real name 😄)
Playwright and Cypress should be "implementation agnostic", so it shouldn't really matter if you're testing a SvelteKit app, or a React app, or maybe even a Laravel / PHP app 😄
That said, SvelteKit's `npm init` wizard will suggest whether you want it to set up Playwright specifically, and I think more of the contributing directly to Svelte & SvelteKit prefer Playwright over Cypress.
Personally, I find them very similar, especially after adding the Testing Library selectors to each. I've got more experience with Cypress and I'm able to use its inspector / debugger much better than the Playwright one. For that reason, I find the Playwright plugin to run its tests right in VSCode essential, it works great!
For a Cypress "drawback" I dislike how they've hardcoded the old school mocha + chai combo. Jest came back to win convincingly, so everyone's used to "Jest expect"-style assertions. I've been watching this thread for years: github.com/cypress-io/cypress/issues/281 It may seem silly, but it takes a moment to switch from the expectations in the Jest / Vitest unit tests to the Cypress tests, it's always better when you've got the same way of doing the same thing!
Now, if I'm trying to *predict the future*, Playwright is a Microsoft product, and believe it or not, most fullstack tech is Microsoft nowadays 😂 VSCode, Typescript, GitHub & NPM... So I think Playwright will manage to leapfrog Cypress eventually, and because they'll keep open-sourcing and including everything for free, more and more people will gravitate towards Playwright. Which will make it an even better idea to choose Playwright as your BDD tool...
For example, they've released experimental support for testing components recently: playwright.dev/docs/test-components
Conversely, Cypress does put some cool features behind a paywall, like automatically recorded runs you can review on their dashboard, which is totally fine by me and will help fund make the project better... but inevitably more people will go for the free tool over the paid one (especially when the free tool is backed by a huge company, it's not something I made 😄!)
Thanks for the great question, and for reading my little essay 😅
@@jmagrippis Thank you so much for the detailed response!! I'm new to testing so it's super helpful. Also, do you think Vitest will overtake Jest one day (at least for vite apps)? I'm building a component library for Svelte and was thinking of testing with Jest/Testing Library until I learned about Vitest from your video. Is there no reason to use Jest anymore, or are there still some things Jest does better despite the more complicated config? Maybe it's still too early to use Vitest for production?
@@widjaja101594 well, you don't ship Vitest / your test code to production, I'd worry more about "is it too early to use Svelte in production?" 😛 (it's not!)
But I get what you're saying, you can proudly ship anything to production with confidence, if you have confidence in your tests! Which is why I would indeed advocate for Vitest for Vite projects.
It's not just that the Jest config is more complicated, it's that you're doing things differently for your tests than in your code, as I say in the video. I've seen countless more bugs related to that disparity (and in general mocking things "wrong", in a way that doesn't reflect reality).
Conversely, I've never seen a bug *because* of the testing framework! I've seen bugs due to badly written tests and missing the forest for the trees, but that's by the by...
So yeah, with Vitest you're avoiding one of the top two causes for shipping errors to production, while Testing Library helps you with the other one (the other top error being writing test that just copy the implementation you've already done).
The other thing I mention in the video is that Vitest is less realistic than Playwright / Cypress, so you don't have supreme confidence whatever you do; But you may find its speed is worth the "it's not actually running in a real browser" confidence hit 🙂
But it's on you to give those tools a go and see how it feels 😄 Are they helping you write your implementation, do you feel "safe" that you are testing the things you want to test, how easy it is you write your test boilerplate, how much time it takes to run your whole test suite, or just the one related to the files you're changing...
All that said, I strongly dislike articles that end with "there are advantages & disadvantages blah blah", so... as you see in most of my repos for these videos, personally I am going for the Vitest / Playwright combo nowadays, although I get to work with other configurations in other projects 🙂
@@jmagrippis Thank you so much!! i'm learning so much from your videos and comments 😃
Great video
Thanks Daniel, I always appreciate reading people liking my videos! 😄🙌
Hi sir, love you video! I would like to ask, since I have some alias in my svelte.config.js, my tests are running errors saying that "Failed to resolve import @/services/service.js". Can you please help me? Thanks!
Hey Ian! Were you using `vitest-svelte-kit`to extract the svelte-kit config as I show in the video? Or were you using latest SvelteKit versions, which automatically have a `vite.config.js` so you don't need to do anything extra to use Vitest?
Aliases work out of the box for me with either of those solutions! If not, I'm afraid it'd be because I'm using Typescript (so the aliases are defined in the `tsconfig.json`) and you don't seem to be?
@@jmagrippis Hey Johnny, thank you so much for your reply! I think that's the problem. I am using plain JavaScript in my Sveltekit application. Should I transition to TypeScript to achieve what you have created?
@@codealongwithkirk I wouldn't say that the problem is you went with Javascript 😛 but I'd gamble you'd have avoided that problem if you had gone with Typescript!
I generally recommend Typescript, I've seen companies favouring candidates with "Typescript experience" too, and all my repos and examples are in Typescript too, so they'd be easier to follow.
Nowadays I find that if Typescript complains about something, it may feel like it's for no reason and you're just doing busywork, but in the end it turns out it was complaining for a legit reason 🙂
So I'd say it's worth trying out, yes!
--
Ah, before moving everything tho, you had run the dev server or build the project, right? (`.svelte-kit` directory exists?)
@@jmagrippis Alright! Thanks Johnny!
@@codealongwithkirk Anytime 🙂 Let me know if it does, or doesn't work out for you!
thx sir
Thanks for keeping up with me Ahmet 😄
can you create a tutorial for nextjs with vitest i am new to testing so i am really stuck
Hey Kakun, thanks for watching! It's exciting you're looking into testing 🙌
If you're using Next.js, it's probably a better idea to look into Jest? Since Next.js is not using Vite, it doesn't really make sense to setup Vitest for your node / unit tests. The core ideas I talk about regarding TDD and stuff in this video still apply!
I've looked into it now, and I have actually done a video on Next.js and Jest, it's even older than this video! I had kinda forgotten about it 😅
czcams.com/video/0DK7FX79WI0/video.html
Things have changed with Next.js since, but I think the setup and spirit should still apply when it comes to setting up Jest! And of course I talk a bit more about testing React components specifically, with React Testing Library.
Thanks again for watching, and do let me know if this gets you anywhere 😄
@jmagrippis oh yes I have looked into your video but at work they decided to use vitest so I am currently trying with your tutorial and some others I guess I'll learn something new but it's just that I feel like writing all these tests consumes much more time
"at work they decided to use vitest..."
Feels like a bad decision 😅 You'll have to setup Vite just for your unit tests? And because of the different setup there's that chance I talk about in this video, that things will be different between "real life" and your tests! Jest is a sensible choice, but if they want to be fast and cool they can also go for BUN which has been getting so much hype this month with its v1 release.
"writing all these tests consumes much more time..."
Haha, writing tests always consumes time for sure, can't be helped! But if you write meaningful tests, you save time every time you refactor or change a piece of code. Instead of manually confirming things still work as expected with your eyeballs, the machine does it for you 😄
And regardless of testing framework (Jest or Vitest or Bun or even e2e tests with Playwright or Cypress) writing meaningful tests is definitely a common skill that carries over, I hope you start feeling those time savings at some point! In theory, the more you release new code, the more you should be thankful to the tests!
(however there can be bad tests, that fail for no real reason, or because you were testing implementation details, and you just do extra work every release to amend them 😅)
awesome
*You* are awesome for watching and commenting 😄
Ugh why the need to install so many things? It seems like you have to install a lib every few seconds. Shouldn't it come configured out of the box
Hey there! I get the sentiment believe me 😅 But you may be happy to know that this video is 8 months old, and the SvelteKit wizard DOES ask nowadays whether you want Vitest configured for you, when you create a new project!
I guess with these things, you want to have all the helpful libraries configured out of the box, but not the useless libraries you don't care to use. So there is a bit of a debate what *should* be included, what should be optional, and what shouldn't be included at all! I like to think getting involved in the community, and maybe even this video helped spark interest in Vitest as it matured itself, people tried it out and decided they do like it and want it over other tools, so it is an optional part of the "default package" now 🙂
That's also why I do try to figure out and explain how things work at the time of the video, instead of just giving you links to the code to copy and paste, because this way some people from the future would still get something meaningful out of the process, even if the specifics of how you actually do it a year down the line will be different.
Thanks for watching and commenting!