So let's get started with creating our new test method for overbooking.
Again, for sure.
For X unit test methods, we have to use the attribute fact.
Then we create a public void and we call it avoids overbooking.
There we go.
And what we do is we create three.
Statements.
First one is given, followed by when and then followed by then.
So given when then.
And this is just what we had in the last presentation.
So what we create first is a flight and we create a new flight and we set the seat capacity to three
afterwards.
We create an error here.
Flight dot we book something.
For yannick@tutorials.com for example.
And as discussed we will book four seats so we have three but we book four which would be an overbooking.
So we expect to get an error here, right?
For sure.
This is not implemented yet.
And then error dot should dot be of type V of type.
There you go over booking error.
This is what we will have to create.
Awesome.
Now let's save this in that way so that we can now take a look at our error list and follow again through
all the errors that we have and implement the logic behind it.
Let's get started with the first error.
Cannot assign void to an implicitly typed variable and we can fix this by changing the return type of
the book method to be type object.
So let's go into the book method.
This is in our flight class, so we got that here book, right?
And we change it to be not void.
Instead it returns an object and we don't always return an object.
And this is why we make it nullable so it can return an object, but it doesn't have to.
So if there is an issue, we will return an error.
That will be our object.
And if everything goes well, we don't return anything else.
So we add return null here, return null for now, that's fine.
So that will fix the compilation error here.
Let's add a new class to our domain layer.
So in domain we can add a new class or we can simply take that class one dot, which we have here.
So let's right click and refactor it and change the name to overbooking error.
So for that specific case where we just have that overbooked scenario for this case, we will create
a completely own class, right?
So there are multiple ways how you can do that.
You don't have to create a class, but we will do it like this.
You can for sure also do something else.
Just create a new exception or whatever.
Now, before we continue, let's first of all run our test to check if everything is working.
So you see in our flight specifications that we don't have any errors anymore and error should be of
type overbooking error.
So let's check right click on it and run tests.
You can now see that we have two tests here which are inside of our test Explorer.
Let's see.
Let's see what happens.
And you can see that avoids overbooking is not passing expected error to be domain overbooking error
but found null.
So what we need to do is we need to return an overbook error in the scenario where we have an actual
overbooking.
Right?
So let's implement the logic behind that Inside of our flight book method.
Here we simply add a simple if statement.
So if the number of seats that we want to book for a flight is bigger than the remaining number of seats
that we have for the flight, we simply return a new overbook error.
This is what we have to do, right?
Pretty simple.
Remember that we have that remaining number of seats for the flight and we just get the information
of how many seats we want to book for flight.
And if the number exceeds the remaining number of well available seats, we would have an overbooked
error.
And for sure we return from here.
So we would never reduce the remaining number of seats actually.
Awesome.
Let's go ahead and run the test again and see if this now passes.
Awesome.
So you can see both of our tests are now working.
We have the avoid overbooking and booking reduces the number of seats.
So both scenarios are working and we use testing for this so we don't have to actually start our application
or our user interface, mobile app web application or whatever.
Enter values and test it in that way.
No.
Instead we have written C-sharp test, which we can simply run with a single click and all at once.
And that's really the absolute power of TDD.
So we first of all discovered a test scenario and then we translated it into test code.
In my experience, the test that's easier to write is also easier to read.
Remember that the first rule of TDD is to write production code only to pass a failing unit test.
So we wrote the test code.
We saw it failing.
Then we followed the errors and fix them one by one until the test passed.
And sometimes you want to test if something is possible or not.
So you can write some exploratory code first to see if it's possible.
Then throw it away and start over with discovering the scenario and writing the test.
First, let's just sum this up again before starting to code.
We should clearly specify what exactly we want to do.
We create a mold using the scenario and pour the production code into it.
From that point forth, the production code cannot behave differently than the initial expectations.
We forged into the mold.
If there's only one thing you take out of this course, I want it to be the red green refactor technique.
These three tiny steps are the core of test driven development.
At the red Step, you design the externally observable behavior of the system under test at the green
step, which is the most trivial step.
You just write enough code to pass the test.
It doesn't matter if the code you write is not clean enough at this point, right?
You should just make the test pass or switch the green state.
In another word, switching to the green step shouldn't take too much time.
At the refactor step, you improve the interior design of the system under test as opposed to the red
step at which you focus on the exterior design of the system under test.
So you shouldn't start writing the next test without considering the interior design of the system.
Under test.
There are lots of patterns you can use for refactoring systems under test, but they are outside of
the scope of this course, however.
Well, congratulations.
And we are at the end of the second chapter now of the test driven development course.
And now you know why Test driven development is super essential.
You can create a new unit project and follow the red green refactor process to write a test.
And in the next chapter you will learn to discover new scenarios and improve the trustworthiness of
your test by parameterizing them.
So definitely stay tuned and see you in the next chapter just in a second.