3 Minutes with Kent

How do I add tests to existing code

04.06.2021 - By Kent C. DoddsPlay

Download our free app to listen on your phone

Download on the App StoreGet it on Google Play

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.

More episodes from 3 Minutes with Kent