So the last question in this email has to do with how do you know why where to start testing because you're adding testing to an existing project and so most of your tests are actually writing tests for code that exists and so it's not like there's no test driven development there or anything like that.

And so, how do you know like how far do I go and testing when when can I stop and say that this component is tested? Does it have to do with code coverage or whatever? And my answer to that is I actually do have a blog post how to get started with testing or how to add tests to an existing code base.

Where I talk about with just kind of in general you want to start with a single end-to-end test and you add some static testing and then you add the tooling for and unit integration and then just add over time and you can go take a look at that for a little bit deeper read on that, but if we're talking specifically about I have this component and I want to add tests to it where do I start and for me it comes down to thinking about use cases more than thinking about code coverage.

And I actually have a blog post ofAbout that as well. But basically the idea is I don't really care about code coverage. Lines of code is basically irrelevant. All that the the code coverage report tells me is the use cases that I'm not covering. That's what I'm thinking about when I'm looking at the code coverage report.

So if there's like an if statement that is not covered then that just says, oh, okay, so whatever use case that code exists for that's a use case that I'm not testing for because use cases are all that we care about. We care about this.Code working for the users whether that be developer users who are calling our functions or rendering our components or end users who are clicking the buttons were rendering whatever.

And so you want to think about the use cases that you're covering and then you weigh them relative to the confidence that you need for other use cases of other components as well as the features that you need to build and bugs you need to fix and things like that.

So it really comes down to what we said before about weighing the return on your investment of time for writing.Versus features that you can work on Now let's say that you live in a world where it doesn't matter You don't need to work on features you can just totally focus on tests.

There is a stopping point for sure and the stopping point is when you feel like you've covered all the use cases. Now for like open source libraries and stuff it typically end up covering all of the use cases you get a hundred percent code coverage, but for applications. I never find myself in a situation where I can just spend a ton of time on tests.

I need to work on features and that's where you just need to kind of weigh, what are the things that I am going to write test for.Versus new features or whatever. Hope that helps Ciao.