Now, our next scenario is that when I book a flight, the flight should contain the booking and there
should be a flight to be able to book it, as you already know.
You might ask, we have covered such a scenario earlier, Are we going to do it again?
Well, this scenario is different because we are considering the scenario at the service level.
The difference is that instead of calling the entities book method, we call the book method of the
booking service.
Calling the book method at this level loads, the entity from the database calls the entities book method
and finally saves it to the database again.
So here we are on a completely different level to check whether the changes have affected the application.
State We ask the booking service for the list of the flights booking and check if the result contains
the booking that we just made and to load the flight entity from the database and book it, the flight
entity should exist in the database already.
Now let's get our hands dirty and write some more tests.
All right.
So let's switch over to our unit test project that we got right here, which is for application tests.
And let's start with the when step.
So first of all, let's create a new booking service.
Let's write down booking service, but you will be able to see and based on the rule of or based on
the second law of TDD, you can see that the name booking service does not exist in the current context
and that for sure is totally correct because we have not created a booking service class yet.
So let's do this right here.
Public class booking service.
There we go.
And let's now create an instance or sorry, there we go, without parentheses for sure.
Booking service.
Let's create Var booking service equals to new booking service.
Right?
So now we have the booking service set up and the error is gone so we can continue.
Let's call the book method from the booking service booking service dot book.
And again, we are at the red state right now because we don't have well, you can see this.
I mean, we got the error information.
Booking service does not contain a definition for book, right?
So now let's set up that book method so that we can continue inside of the booking service, create
a public void, let's call it book.
And again, we don't take care about too much production code.
We don't talk about logic only fixing errors step by step.
Now for sure, we need to transfer some information here.
So booking service dot book.
So which flight do you want to book for?
How many people and for which email address and all of that?
Right.
So we need some sort of information here.
And for that, usually you would create a so-called data transfer object, DTO So let's submit here
a new book, DTO book, data transfer object that mainly contains just some information.
And again, we are at a red state now, so we need to fix that issue here to get to the green state
again to be able to continue.
So let's create our book.
DTO right under the class booking service, public class book.
DTO There we go.
Now we are at a green state again because you can see that we have the new book here.
So now we have implemented the book.
DTO, you can see that we have one error left which is no overload for method book takes one argument,
which is and this is caused because right now we are submitting a parameter here, but book method for
sure does not take a parameter.
So let's adjust that and add book DTO here.
Let's call it book DTO now we are back at a green state, so no errors anymore.
So we create a booking service.
We book a flight here and afterwards we need to find that flight again as we have discussed it in the
earlier presentation.
So let's call, find bookings.
We can call it like this, find bookings.
There we go.
And again, we are at a red state.
So inside of our booking service, create another method.
Public void find bookings.
There we go.
No curly braces instead.
Nice.
Find bookings.
And we are at a green state again.
So for our next steps, we will again need the fluent assertions.
We have that installed, but not for this project here.
So what we do is go to tools, package solutions, go to installed.
This time you can see fluent assertions here and let's enable it for application dot tests.
Hit install.
Perfect.
Now we can close it again.
And right now I can just see that I forget to refactor the name correctly.
So here, take flight application specifications and go to applications test and take the unit test
file here and rename it to flight application specifications so that it's now well updated correctly.
Awesome.
Now is the class name matching to the file name perfect.
Our find bookings.
I mean, the name is already telling it.
That should return a list or collection of bookings.
So instead of having that public void, find bookings, let's switch the type over to Enumerable.
For that we need the system collections namespace using system dot collections.
There we go.
And then we can take public I enumerable of type booking which is read model.
So m stands for read model.
And again we are at a red state so we have to fix that now under book DTO create a new class, call
it booking.
M Let me just explain you the difference between DTO and an M I mean, mainly this is not really related
to TDD, but I know there are a lot of people out there who might not come from web development or have
no clue about how to write like Ruby real world applications, right?
So a DTO is for transferring data book, DTO write data transfer object, and a booking is a read model
which also contains information.
So this one is like sending information between A and B and read model is usually used to provide specific
informations.
Okay, let's move on and throw a not implemented exception here.
Throw new not implemented exception implemented exception.
I'm missing the namespace, but that's not a problem.
I can just implement it here.
Show potential fixes using system.
And now we need to adjust the namespace.
It's not using system collections, it's collections generic.
Yeah.
And that should fix the issue.
Perfect.
Nice.
So let's check if our find booking returns.
Any information.
Let's scroll up here and find bookings.
Let's go ahead find bookings.
Dot should Now let's start using the fluent assertion.
So show potential fixes and implement the using directive here using fluent assertions.
Now we can continue dot should dot contain an equivalent of let's create a new object here.
Let me just do zoom out a little bit.
Contain equivalent of a new booking model.
All right.
There we go.
So we expect that our find bookings method returns a collection.
And inside of that collection, we expect to have a new empty booking.
Right.
And you can tell that things are now getting a little bit more complicated.
And this is because while we apply all of that stuff now to a real world architecture, so to a completely
new level or to a completely new layer, and that makes things just a little bit more complicated.
However, we are at the green state and we now have a good point to actually test our application here.
So right click, let's run tests.
You can see that we now have another testing project here.
Application to test.
Right.
And you will be able to see that all of them will fail.
Actually, it's just one.
Right.
But that one should fail now.
Right.
And it's because not implemented exception.
So the method operation is not implemented.
And that for sure is totally fine because fine bookings gets cold, but it's not implemented.
So we throw an exception which causes the test to fail.
So next up, we will continue working on that because the scenario here is a little bit bigger and we
have a more real world sort of structure.