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 topronounce this name. It looks like pejor or push actor. I'm not surethey're from the Netherlands. And anyway, they actually wrote me quite anice email about testing JavaScript.com and just had some additionalquestions because the course mostly goes into the how to get things doneand that doesn't get as much into like some of the philosoph well itactually 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 thenyou'll see I've got dozens of blog posts about testing and so that's kindof 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 and

whatnot?To write test for and why? So and they acknowledge that yes youwant to avoid testing implementation details but how do you know thatyou're done writing tests for a component? So for one thing I actuallyrecently had a question from somebody who said like should I makeassertions that certain things don't show up in my output, you know, sowe're asserting that the login button shows up and I can click on it butlike should I also assert that the register button doesn't show up orwhatever 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 workingon 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 bitof an art but you generally just think okay, so I'm gonna write this testfor this component and the reason that I'm doing it isn't just to write atest 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 thinkokay so I could write some more tests for this component and maybe I'vebeen 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 takes

from the time aspect versus the amount of benefit with more confidence ornice 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 youwant 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.