Today I was in a piano discussion for test JS Summit and a question was asked about like what's the use case for unit tests if we focus on integration and component level tests. And I talked about this and and it was kind of more about like what what's the shape of our testing trophy or testing pyramid or whatever like where do we focus our tests?

And I talk about how I recommend that you focus on integration and component-type tests and try to mock as little as possible. I typically don't mock modules all that often and most often will just.Mock HTTP requests unless we're doing end tests in which case you mock nothing. And the the way that I think about it is like if you just have 100% unit tests and that's all that you're writing and you get a hundred percent code coverage with that you're still very likely to have lots of bugs creep up as integrations between different pieces of these units change.

And that can be very difficult to track when you are just mocking all the modules and just unit unit testing everything. And so you're gonna start moving over to component or integration.And type tests and with that you end up realizing that you don't need those unit tests as much because they're covered by the integration test and so okay now we just don't bother writing those and we just focus on integration tests but event at some point if you just say, oh let's just do all integration tests you're gonna find that it's a lot very repetitive to cover certain cases.

Maybe you have some functions that are doing some computations in there a lot of different parts of the algorithm that you're using or whatever, you know, tons of branches if statements turn areas all over the place that you have to cover.To you know feel confident that you can ship this code And so those are the types of things that I actually move over to unit testing.

And so we'll have a single integration task that's or maybe a handful of integration tests that are testing the more common use cases, but then you'd have a unit test for the specific unit of code that is more complex. It's typically these are going to be pure functions but not always but they'll often be pure functions that you just call it with some arguments.

You get some result back. And these types of tests run really fast and they're really quite easy to run.And maintain and so that's kind of where I see unit tests fit into the spectrum of what types of tests that you write. I've written about this on my blog.

If you go to https://kcd.im/trophy, you'll find it it's a static versus unit versus integration versus end testing. A kind of lays out the differences there. Anyway, I hope that's helpful to you have a wonderful awesome day and we'll chat with you later.