After making the case why testing is important and everyone is on board with it, one of the biggest questions arise. What should I actually test? This question is incredibly hard to answer precisely. So I have one rule of thumb.
Look at a piece of code and ask yourself, would it be bad for the application if this code would break? This helps me personally in getting my priorities very straight. but what are the most critical pieces of my application? Before we jump to the second most important question, let's look at this piece of code.
What we have here is a user class that might give me access to interesting user information, like the full name of the user, if the user is an admin, or if the user's current session is valid. There's a lot of information we can extend of this one. At first glance, there's quite some stuff going on here. Probably the user class will be very important for our system going forward.
So what should I test? I should probably test everything, right? That is the right moment for me to have wrote a second most important question to you. What does actually make sense to test?
Let's answer this together by stepping through the code and make note about the lines we care for and let's ignore the others. So let's start with the constructor. The constructor seems like something we really want to test immediately. But actually I would say at this point No We do not care for the constructor to be tested individually It is called in every single other test that we're going to use So we don't need to test if this user class gets instantiated because this is something we can cover in other tests So we can't ignore this one for now Especially there's something in there like traits.
We don't want to check for traits because apparently they're nowhere use right now in the code And session start is also quite an interesting one, but we might not care in the initial user implementation about this one. Let's look at the second one. The name, this is a very clear yes. This is a nice and simple test that gives me one clear result.
And it would directly imply that the constructor is actually working. So this is a good one to test. Next is the user and admin. For me, this is also a very clear yes.
In this case, it's a little tricky though. This shouldn't be tested on the outcome if the user is actually an admin, but what I really care for is that permission granted gets called as we want to. As we've seen before, permissions is an import piece here, so we kind of care that this works and less about the outcome here. What about current session is valid?
This is a partial yes. I see there's a second thing. to tackle sessions. So I would try to say, yeah, test it, but let's try to combine it.
So current session valid should be tested in favor of using ExtendSession as well. Overall, let's summarize this by saying we should test small important pieces of our code, but mostly focus on things related to the user flow. If you've heard of the term test coverage, That means how much code is actually covered by a test. This always results in a percentage number like...
If we run this, for example, we would have tested about like 80-90% of the code. Right now we have no test written, so we're at 0%. If we would have a test on every single line, we would be about 100%. Let me state right away that 100% is not always necessary and sometimes not even possible.
We might achieve it here... but don't necessarily make 100% the standard you're thriving for. Something around 80% is healthy and goes well with the two important questions we have established. After making the case why testing is important and everyone is on board with it, one of the biggest questions arise.
What should I actually test? This question is incredibly hard to answer precisely. So I have one rule of thumb. Look at a piece of code and ask yourself, would it be bad for the application if this code would break?
This helps me personally in getting my priorities very straight. but what are the most critical pieces of my application? Before we jump to the second most important question, let's look at this piece of code. What we have here is a user class that might give me access to interesting user information, like the full name of the user, if the user is an admin, or if the user's current session is valid.
There's a lot of information we can extend of this one. At first glance, there's quite some stuff going on here. Probably the user class will be very important for our system going forward. So what should I test?
I should probably test everything, right? That is the right moment for me to have wrote a second most important question to you. What does actually make sense to test? Let's answer this together by stepping through the code and make note about the lines we care for and let's ignore the others.
So let's start with the constructor. The constructor seems like something we really want to test immediately. But actually I would say at this point No We do not care for the constructor to be tested individually It is called in every single other test that we're going to use So we don't need to test if this user class gets instantiated because this is something we can cover in other tests So we can't ignore this one for now Especially there's something in there like traits. We don't want to check for traits because apparently they're nowhere use right now in the code And session start is also quite an interesting one, but we might not care in the initial user implementation about this one.
Let's look at the second one. The name, this is a very clear yes. This is a nice and simple test that gives me one clear result. And it would directly imply that the constructor is actually working.
So this is a good one to test. Next is the user and admin. For me, this is also a very clear yes. In this case, it's a little tricky though.
This shouldn't be tested on the outcome if the user is actually an admin, but what I really care for is that permission granted gets called as we want to. As we've seen before, permissions is an import piece here, so we kind of care that this works and less about the outcome here. What about current session is valid? This is a partial yes.
I see there's a second thing. to tackle sessions. So I would try to say, yeah, test it, but let's try to combine it. So current session valid should be tested in favor of using ExtendSession as well.
Overall, let's summarize this by saying we should test small important pieces of our code, but mostly focus on things related to the user flow. If you've heard of the term test coverage, That means how much code is actually covered by a test. This always results in a percentage number like... If we run this, for example, we would have tested about like 80-90% of the code.
Right now we have no test written, so we're at 0%. If we would have a test on every single line, we would be about 100%. Let me state right away that 100% is not always necessary and sometimes not even possible. We might achieve it here...
but don't necessarily make 100% the standard you're thriving for. Something around 80% is healthy and goes well with the two important questions we have established.