How do I add tests to existing code - a podcast by Kent C. Dodds

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 andso 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 codecoverage 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 existingcode base.
Where I talk about with just kind of in general you want to start with asingle 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 toit 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 casesthat 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 whoare 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 casesof 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 onNow 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 ahundred 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 featuresor whatever. Hope that helps Ciao.

Further episodes of 3 Minutes with Kent

Further podcasts by Kent C. Dodds

Website of Kent C. Dodds