Okay, So in our flight specifications, let's create the test for canceling a flight, which then frees
up seats.
So as we have discovered that scenario in the last presentation, let's now create a new test method.
So write down fact public void.
What does it do?
So cancelling bookings frees up the seats.
This is exactly the scenario that we are trying to write a test for.
So once we cancel the booking, the booked seats available after cancellation, let's get started with
the given step.
So var flight equals to new flight.
We create a flight which has three seats available now.
The second given step is flight dot book.
So we book a flight for passenger email, let's say a etb.com for a number of seats.
One.
Now let's add the one step flight dot.
We want to have a method maybe, which is called cancel.
Booking.
Cancel booking.
That's fine.
Let me just zoom in a little bit more like this flight, cancel booking and we want to cancel it by
providing the passenger email.
Again.
Passenger email.
You can write it down like this.
atb.com.
And for sure also again the number of seats which then would be.
Like, let me copy that over from here.
So number of seats and again, one.
Okay.
So this would be a test scenario for the one step, that new method which takes in a passenger email
and the number of seats to make them available again.
Now it's time to practice the second law of TDD.
So write no more of a unit test than sufficient to fail.
It's important to remember that compilation failures are also failures.
So as you can see right here in our error list, we have errors.
So right now we should not write any more.
We should stop here and work our way through the error list right now, As you can see right now, the
compilation is failing because the cancel booking is not defined for the flight class.
Well, now you might be asking, should I continue to implement the following step, which is then or
should I fix this error here first?
So based on the second law of TDD, you should fix this one here first because something meaningful
is missing from the production code.
Now let's try to use refactoring tools to generate that method automatically.
Simply hold the cursor above the missing method.
You can see show potential fixes or simply press control Dot Which brings up a small menu.
And you can see generate method cancel bookings.
So let's do that.
Click on that.
It will automatically perform an action.
Let's press Ctrl F12 and you can see public void cancel bookings, string passenger email number of
seats not implemented.
Perfect.
But now that one is fixed because we now have it implemented.
But now the issue from the flight specification is fixed even though we have no logic inside here.
Okay.
So now the second rule of TDD is actually well, not appearing anymore, right?
So we can continue and add the next step, which is the then step.
So let me write that down here because that's a little bit awkward or a little bit weird to pronounce,
right?
That then step.
So this is given.
And the other one here is also given and this is the one step.
And then we have the third one, which is the then step, which is the then step.
Right?
So awesome flight dot remaining number of seats dot should dot be three.
So let's discover that scenario again.
We create a flight with three seats.
We book one seat so we have two left.
Then we cancel the booking and free up that one seat again.
So we will come back to three seats, right?
So this is the scenario given is the actual flight.
And then we perform an action which is the one step.
And finally we check for the result, which is the then step.
Okay.
Right click on it.
Let's run the test and we will have no compilation errors because our error list is for sure clean.
But for sure we will run into some runtime errors because we don't have that cancel booking logic or
production code implemented yet.
Okay.
Here we have our result.
Let's check the cancel.
Booking frees up the seat should fail.
There we go.
You can also right click on a specific test and run it instead of running all of them all the time.
Right.
So feel free to only run the failing tests if you want to save some time, but make sure to well run
all tests on a regular basis.
Okay.
So the third law of TDD says write no more production code than sufficient to pass the test.
Now let's write the minimum amount of code to pass all of the tests.
Let's switch to devil's advocate side right here.
Let's go into the flight class, cancel booking here.
Let's simply set the remaining remaining number of seats to three.
Right?
So take a look at the testing scenario again, Should remaining number of seats should be three.
Right.
And we set it to three because we're devil's advocate.
That's not how the logic should be implemented.
Right.
But from a devil's advocate side, from that game, the test will now pass.
So right click and let's run the test.
Yeah, you can see that this one is now working.
Now your next question should be what are the important variables in this test?
For sure it is initial capacity, the number of seats to book, the number of seats to cancel and the
remaining number of seats.
So let's bring that into the parameter here because we now need to parameterize this test to make it
as easy as possible for us to play the devil's advocate game and write a test for multiple testing values.
So let's get started.
INT initial capacity.
Next one is int number of seats to book.
Next up, int number of seats to cancel.
And last one remaining number of seats.
There we go.
Perfect.
So now we have our parameters set up.
Let's go ahead and since we want to parameterize it, we don't use fact.
Instead we use.
Instead we use theory.
Awesome.
Now what we can do for sure is we can set inline data and take the values for the first test, which
we have right now, which is 3113 for sure.
Pay attention that you set the values for the correct parameters.
So initial capacity three Then we book one seat, then we want to cancel one seat again and the remaining
number should be three.
So 3113.
That makes sense to me.
Awesome.
Now let's use our parameters.
Initial capacity here.
Number of seats to book.
We get that right here.
Number of seats to cancel.
We got that here and remaining number of seats is in the then step.
There we go.
Let's save it and let's restart the test.
It should still pass for sure, but now we can easily play the devil's advocate game.
So let's just give it a second here.
Yeah.
And it's passing.
That's perfect.
Let's try to set some inline data.
Some different inline data.
Right.
Let's add four initial seats.
Two of them get booked.
Later on, we want to cancel two of them.
So we got four again.
Okay, now it's time to start the test again.
So right click run test.
As I said, you can also go into the Test Explorer, keep that open and just restart the single test
that saves you some time.
However, that one should now be failing because the actual result is not correct.
For the second test, it should be four.
But he found three because we hardcoded it here.
We played the devil's advocate game and we now well have to change the production code, the logic code
of the cancel booking implementation.
Okay, so let's finish that up.
Write one more inline data and this time we use like seven initial seats and we book five and then we
cancel four.
So we should result in six seats available, right?
So we have seven available seats, we booked five, we cancel four.
So we result in six available seats remaining.
Awesome.
Let's switch over to our implementation of the cancel booking logic.
So we are freeing seats up again.
So we're canceling.
That's why we take the remaining number of seats and increase it by the amount of number of seats.
So that should be the correct implementation.
And the great thing about this is that we can simply test it.
So right click run tests again and it should now pass all the tests available and we have used all laws
of TDD to write that test well and that is absolutely professional.
So right now we have tested this method for three different values or set of values and we can say that
our test is very trustworthy right now.