How to know when you're done testing something - a podcast by Kent C. Dodds

Hey your friends So I am going to for the next couple days answer some
questions that I got in an email from somebody. I don't know how to
pronounce this name. It looks like pejor or push actor. I'm not sure
they're from the Netherlands. And anyway, they actually wrote me quite a
nice email about testing JavaScript.com and just had some additionalquestions because the course mostly goes into the how to get things done
and that doesn't get as much into like some of the philosoph well it
actually yeah, we we get into that a bit.But there's no like specific lesson on how to write your code, so it's
testable or whatever. So anyway, um, most of that knowledge I share on myblog. So if you go to Cansee dots.com slash blog and then type in test then
you'll see I've got dozens of blog posts about testing and so that's kind
of where I direct people to for when they have questions like this, but Ithought I just answered a couple of these on the three-minute podcast.
So for this first one, the question is what should you write tests for andwhatnot?To write test for and why? So and they acknowledge that yes you
want to avoid testing implementation details but how do you know thatyou're done writing tests for a component? So for one thing I actually
recently had a question from somebody who said like should I makeassertions that certain things don't show up in my output, you know, so
we're asserting that the login button shows up and I can click on it but
like should I also assert that the register button doesn't show up or
whatever the case may be?And,So anyway the answer to this question is everything that you do in
software is trade-off and it has a cost and that cost is equal foreverything and the cost is your time. So how much time do you spend working
on any given problem and and you weigh everything relative to the amount ofbenefit that you get for the time and it isn't exactly a science is a bit
of an art but you generally just think okay, so I'm gonna write this test
for this component and the reason that I'm doing it isn't just to write a
test but it's because what I get out of writing it.
To test is more confidence And so at every moment of the day or wheneveryou're making it a decision on what you should work on you should think
okay so I could write some more tests for this component and maybe I've
been working on this component working on its test or I could go implementthis new feature or fix this bag or whatever.
And you just have to decide okay based on the amount of cost that it takesfrom the time aspect versus the amount of benefit with more confidence or
nice feature for more users or whatever and you just weigh those and make adecision on what is most valuable. So you're not just testing because you
want to tend to.Ask but you're testing because you're trying to get something out of it. I
hope that's helpful. Good luck.

Further episodes of 3 Minutes with Kent

Further podcasts by Kent C. Dodds

Website of Kent C. Dodds