Nice overview! Regarding snapshot tests: They're kind of a middle ground between a unit and integration test. You render your component (kind of like an integration test with Puppeteer or similar) and once you've made changes you as a dev can easily see what real world DOM changes your code change corresponds to. I call it a "poor man's integration test" because it's much easier to set up than an actual integration test.
Hey Scott, do you thing is now “safe” to use on production? We will start writing unit tests for a new project, based on your experience with vitest, would you recommend it!? Does it also works fine with react testing library?
The docs have some examples using RTL: vitest.dev/guide/#examples As for it being safe, the site used to warn that it wasn't ready for production, but that seems to be gone now. It seems to already do pretty much everything you'd expect or need from a regular Jest setup, so I'd recommend you try it and if you hit a point where it doesn't, it should be trivial to switch back to Jest since the APIs are almost the same.
It helps to quickly find regression issues, especially if you have multiple people working on a project. One person might change a component, then run the tests and have a snapshot test fail because it affected the output of another component that uses the one that changed. Now they know to check that one and make sure it's still okay. If it is, it's pretty trivial to run the test again and update the snapshot at the same time, and commit the updated snapshots with the updated tests so it all passes in the CI/CD too.
@@syntaxfm It's doubling up on the LoC for what boils down to be commentary on how your code is supposed to work. Also, what about "Separation of Concerns" and "SOLID principles" and all that?
@@Wzymedia The Vitest docs + Vite show you how you can use dead code elimination to remove the test code from your bundle, so having the extra lines isn't a concern here, but I do know that some people love having separated concerns. That said, colocating things has become more common in the modern component based world. To me that's not a major concern and is something I've grown fond of in Rust.
@@syntaxfm With what I said in mind, I am someone who loves commenting code. I will have more comments than code and that feels natural to me. In fact, at times I think some code looks "naked" without comments... yet I find this inline tests thing weird.
@@Wzymedia sorry to barge in the conversation, but your stance regarding comments is what I find "if-y". Good, clean code barely needs any comments, because you can read that code like text, (or like prose, as Uncle Bob would say). If you give appropriate names to your functions, variables, use explanatory variables, etc, you will barely need comments. My code barely has comments because of this. If your functions are so convoluted that they need tons of comments, you should break them up, make them simpler, etc.
🧡Vitest is here to save the day. Would love to see a course on LUTs covering this.
Been using it since 0.2 and it does wonders. A gift from the lord!
Nice overview! Regarding snapshot tests: They're kind of a middle ground between a unit and integration test.
You render your component (kind of like an integration test with Puppeteer or similar) and once you've made changes you as a dev can easily see what real world DOM changes your code change corresponds to.
I call it a "poor man's integration test" because it's much easier to set up than an actual integration test.
Great video as always, Scott. Been using Jest for a while and it's been feeling a bit ill-suited for modernJS projects. So glad I found this.
Hey Scott, do you thing is now “safe” to use on production? We will start writing unit tests for a new project, based on your experience with vitest, would you recommend it!? Does it also works fine with react testing library?
The docs have some examples using RTL:
vitest.dev/guide/#examples
As for it being safe, the site used to warn that it wasn't ready for production, but that seems to be gone now.
It seems to already do pretty much everything you'd expect or need from a regular Jest setup, so I'd recommend you try it and if you hit a point where it doesn't, it should be trivial to switch back to Jest since the APIs are almost the same.
Anthony's cat is the main contributor to Vitest.
Nice one, going to do some test on a sveltekit project
I use it for tdd, great tool
is there like a reason that people still use jest snapshot
It's fast and easy.
It helps to quickly find regression issues, especially if you have multiple people working on a project.
One person might change a component, then run the tests and have a snapshot test fail because it affected the output of another component that uses the one that changed.
Now they know to check that one and make sure it's still okay. If it is, it's pretty trivial to run the test again and update the snapshot at the same time, and commit the updated snapshots with the updated tests so it all passes in the CI/CD too.
That Rust-like inline testing thing is more than a bit "if-y"...
Why do you say that?
@@syntaxfm It's doubling up on the LoC for what boils down to be commentary on how your code is supposed to work. Also, what about "Separation of Concerns" and "SOLID principles" and all that?
@@Wzymedia The Vitest docs + Vite show you how you can use dead code elimination to remove the test code from your bundle, so having the extra lines isn't a concern here, but I do know that some people love having separated concerns. That said, colocating things has become more common in the modern component based world. To me that's not a major concern and is something I've grown fond of in Rust.
@@syntaxfm With what I said in mind, I am someone who loves commenting code. I will have more comments than code and that feels natural to me. In fact, at times I think some code looks "naked" without comments... yet I find this inline tests thing weird.
@@Wzymedia sorry to barge in the conversation, but your stance regarding comments is what I find "if-y". Good, clean code barely needs any comments, because you can read that code like text, (or like prose, as Uncle Bob would say). If you give appropriate names to your functions, variables, use explanatory variables, etc, you will barely need comments.
My code barely has comments because of this. If your functions are so convoluted that they need tons of comments, you should break them up, make them simpler, etc.