Now let's play the devil's advocate game here.
We have that test which says booking reduces the number of seats.
So we have a flight, we book a flight.
We have initially three seats.
We reduce it by one because we book one seat.
So the remaining number of seats should be two, right?
So it would be absolutely fine to simply go into the book method.
Let's do that and to simply set the remaining number of seats to two so we don't have to subtract it
and we don't need to use the parameter at all from the devil side, right?
We can simply say remaining number of seats is equal to two and the test will pass.
So let me just copy that line comment that one out here.
There we go, paste it in and simply set it to exactly two.
So the remaining number of seats is two.
So check again what the test is looking for.
Flight remaining Number of seats should be two.
So this will pass.
Let's check that right click run test.
And as you can see, all tests have passed and that's definitely another scenario for the devil's advocate
example.
So how can we fix this now from a TDD perspective, it's pretty simple.
Let's simply copy over.
The entire test is absolutely no problem to write the similar test with some different values.
So it's not like repeating write in a basic functional code.
When you program some logic, you have that approach of dry.
Don't repeat yourself for testing.
That approach is not really taking place because it's okay to test different scenarios but use the same
code over and over again.
So booking reduces the number of seats.
Well, the second version of that testing method right now, let's just write down different values
here.
We create a flight with six seats and we book three.
So the remaining number of seats should be three.
And now let's see, I guess you could tell if we right click and run the test, it will no longer pass.
So now we have four tests.
One is not run yet.
Let's just give it a second and you can see that one failed.
So it's not working.
And by the way, we for sure only want to deploy our application once all tests are passing.
Right?
If there is a single test failing, we for sure don't want to deploy our application because something
is not working as intended.
Now let's get back to our flight class and again use our parameter.
So remaining number of seats decrease by number of seats from the parameter that should fix the issue.
Again, let's switch over, let's rerun the tests.
And now you can see that we again have four and now you can see that all tests have passed successfully.
Now, let me explain something to you what maybe some developers of you have already faced.
So instead of the flight method, you maybe have seen something like that.
So let me just again comment that out.
We could potentially say, well, if number of seats is equals to one, then remaining number of seats
is equal to two.
Sorry, there we go.
Equals to run remaining number of seats equals to two or something like if number of seats is equals
to three, then remaining number of seats equals to three.
So using some sort of magic numbers here and hard coding values, right?
So this is for sure something.
Yeah, it depends on the use case, but a lot of times some beginners are doing that.
So here we have some magic numbers and this is for sure really like it's not variable, right?
So it's hard coded.
But in that scenario that we have right here, our test would still pass and that would be wrong.
So I mean, it's always like thinking about what's the probability of that developer is doing such things.
So in order to well, increase the chance of our test being really as trustworthy as possible, we could
now go ahead, duplicate it again, set it to three and again, change the values to be like ten and
six.
And then we have like should be four.
And if we save it like this now again, it would be failing because the values here are not set well
in that way that the test would still pass.
It's very unlikely that now we would have another if statement.
It would be very unlikely that we would already have those lines of code.
But it's more unlikely or even more unlikely that we have lines which are, for example, like this.
Right?
So it's just like those stuff could break our tests, but it's unlikely that we have it.
But sometimes it might be that we have such an if statement here.
So it's good to have more test scenarios with different values just to increase the test worthiness
of your code.
So the only thing that you now should remember is that it's good to test for, well, multiple values
and not.
For a single value, like we did it here, right?
So here we have six and three, here we have ten and six and here we have three and one, for example.
So we tested with different values so that we can make sure that the algorithm that the programmer has
written down is not unintentionally breaking our tests.
So this was a typical example of the devil's advocate game.
One side is trying to break the tests and to make them untrustworthy and the other side is trying to
write more tests and better tests to increase the trustworthiness of the tests.