Time for our very last test.
So we're gonna make sure that we have the ability to successfully reserve a ticket inside this test.
We do still have to do a little bit of setup.
We need to make sure that there is a ticket inside the database that is free and not reserved.
So we're going to first create a ticket save it to the database and then make a request and attempt
to reserve it.
So we'll first create a ticket with our ticket duck billed.
We'll give this the title of concert in a price of twenty and then we can save that ticket
after the ticket has been saved.
We can then make a request and attempt to reserve it.
So it will be a request vary so much what we wrote just a moment ago.
The only difference is we will expect to get back a status code of 2 0 1 which indicates that the order
has actually been created they will do and await request to at you want to make a post to API orders
not send just yet.
We want to set.
That's better.
Set our cookie to global that sign in just to make sure we are authenticated then we can send along
the ticket idea so ticket I.D. is that tickets I.D. so we'll make sure we put in ticket dot I.D. And
then finally we will expect this to resolved with a two a one indicating that the order was created.
So let's save that go back over to our terminal and it looks like it is passing just to make sure it
is passing for the correct reasons.
I will flip back over change that expectation to a four hundred just to make sure that if we have an
incorrect expectation here the test does fail and yet looks good.
So we expected a 400 but we actually got a two a one which means that the ticket was actually saved
in theory to the database successfully we can change that back to two a one and we should be at green
again.
Now naturally we could kind of do a follow up on this test right here.
We could tried to write out something it says hey let's reach into the order collection.
Make sure there are no orders inside there.
And then after making the request take another look at the order collection and assert that there is
at least one order inside our request handler right here actually does send the order as well so we
could potentially also get the response back.
Take a look at the order that was created and attempt to find it inside of our order collection.
So a lot of different ways we can improve upon this to make sure that the order truly is safe to the
database.
But again right now a two a one is kind of good enough for me.
I've got a reasonable degree of certainty that if I get down to this line of code I've successfully
executed the safe.
But again we might end up coming back and changing this code in the future and some other engineer might
accidently do that right there.
They might come in out everything and then maybe remove sending back the order.
So if we save this our orders mean our test was still passed successfully even though our code is definitely
not doing the right thing.
So if you want to you could definitely add in that extra little check to make sure that everything truly
is working as expected.
But right now I think this is good enough for me.
Just we don't spend a ton of time writing tests yet.
So that's it for tests around our new root handler.
Now I want to point out once again I know writing tests is sometimes a little bit of a pain but it was
super critical to do in this case.
Right now we don't really have any way of manually testing our order service and any kind of development
environment the orders service itself doesn't have any functionality tied to it for creating a ticket.
We don't have any way to somehow load up a order or severe ticket into the order service.
And so we would have not been able to make sure that the order could somehow reserve a ticket successfully
if we launch this thing inside of our communities cluster right now and started sending requests to
it through postman.
So this really is a scenario we're writing out some tests is strictly mandatory.
It has to be done as we just otherwise don't know if this root handler is working as expected.
All right.
Now we've got this but together we still do have to take care of some event related stuff and we still
got a couple of other root handlers to get through.
So as usual quick pause come back in just a moment.