Our tests around the ticket update listener are looking pretty good but both the tests we have right
now are really happy Pap tests there assume that everything is working as expected.
I'd really like to add in at least one test to make sure that we can handle kind of bad scenarios as
well.
Let me show you a diagram and explain what I would like to test.
Back to the side gram.
We've looked at it many times.
We're going to assume that inside of our orders database we've got a ticket with an idea Susie Q and
A version of 1 Well then imagine that these two events right here get emitted and now maybe for whatever
reason we accidentally process this second update event first.
That is not what we would want.
We would want to always process this event with the version to first but as we've seen it is entirely
possible that we will accidentally process these things out of order.
So in this scenario we've got a version of three on the incoming event but we still have only version
1 inside of our database and so it's very clear that we are missing the event with version 2.
So in this scenario we would want to either throw an error or at the very least make sure that we do
not call the ACH function.
Remember if we call the act function that means we are acknowledging the message and we are telling
that string server that this event has been processed.
If we just don't call the act function then that streaming server is going to try to emit this event
again.
Five seconds in the future and hopefully in that window we will have enough time to process the version
to even that's it.
That's all we're going to test.
We're going to once again create an instance of our listener.
We're going to create our data event and we're going to give it a version kind of far into the future
and then just make sure that either we throw an error or at the very least that we do not call the ACH
function.
All right.
So back inside my editor I'm gonna go down to the very bottom and I'll say it does not call EQ if the
event is in the future.
Or how about if the event has a future version.
Or how about has a skipped version number or something like that.
I'm sure you could think of a better description the one I've got good enough.
I'll make sure I marked this function as a sink and inside of here we'll get message data listener.
I don't think we need the ticket but let's get it anyways we might need it now we need to somehow make
sure that our data object has a version that is far into the future so a future version we can do so
very easily by just taking a look at the version property on there and sending it to some future version
number.
I'll just say data dot version equal to 10.
That's definitely very far in the future and certainly there are some missing version events between
the one that our ticket has or the current tickets version and this version of 10 right here.
So now we will call our listener on message with that data object and message so when we run this now
we should end up.
If we go back over to the listener itself you're sick.
Update listener when we run this query we should not be finding a ticket at all.
We should enter this if statement and end up throwing in air and so we want to make sure that we somehow
capture that air inside of our tests as we don't want to actually throw it inside the test itself.
We need to capture that thing and then hopefully also write out some kind of expectation that says that
the message not at function does not get called to do so.
I'm going to wrap this thing with a try catch statement
in this case.
We're not really gonna do anything inside of the catch we're just using that catch to make sure that
we do not throw an air out of this entire test which would automatically cause the entire thing to fail.
Then right after the try catch statement we can put in an expectation we're going to expect message
not ask not to have been called.
That's our goal here.
We want to make sure that we did not call that act function.
Let's say this and see how we're doing back over at the terminal and it looks like our update listener
tests are still passing as usual.
Let's try to make this thing fail.
Just make sure that the test is really working as expected.
So how about in this scenario.
Let's try changing about the data version right here.
Let's just come at that out.
So now we should have some accurate or correct version and we should be calling the ACT function.
They'll say that pull it back over
and there we go.
So we got an error here because the act function was actually called well so oncoming that and I think
we're good to go all right.
So I think that's a good series of tests around our on message function.
Let's take a pause right here.
And as usual continue in just a moment.