BRIEFS logo BRIEFS

How to know when you're done testing something

03/31/2021 , 2m, 59s

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 additional questions 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 my blog. 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 I thought 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 and whatnot?To write test for and why? So and they acknowledge that yes you want to avoid testing implementation details but how do you know that you're done writing tests for a component? So for one thing I actually recently had a question from somebody who said like should I make assertions 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 for everything 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 of benefit 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 whenever you'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 implement this new feature or fix this bag or whatever.

And you just have to decide okay based on the amount of cost that it takes from 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 a decision 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.