1
00:00:01,090 --> 00:00:06,010
Let's write a test to make sure this Optimistic concurrency control stuff works as expected.

2
00:00:06,010 --> 00:00:06,910
So here's the general idea.

3
00:00:06,940 --> 00:00:08,210
Here's what we're gonna test.

4
00:00:08,260 --> 00:00:17,520
We're going to first read an instance of a ticket we're going to save the ticket to the database we're

5
00:00:17,520 --> 00:00:23,260
then going to fetch the ticket twice you're gonna fetch it two separate times three essentially have

6
00:00:23,280 --> 00:00:28,260
two separate handles onto a ticket and they're both going to have some initial version flags set to

7
00:00:28,260 --> 00:00:35,110
either 0 or 1 whatever the default is for the module that we just grabbed we're then going to make two

8
00:00:35,170 --> 00:00:39,460
separate changes to the tickets we fetch.

9
00:00:39,460 --> 00:00:43,780
When I say two separate I mean to say we're gonna make one change to the first ticket we fetch another

10
00:00:43,780 --> 00:00:50,980
change to the second ticket we fetch we're then going to save the first batch ticket and we're going

11
00:00:50,980 --> 00:00:55,690
to expect that that is going to work as expected because the first fetch ticket is going to have a version

12
00:00:55,690 --> 00:01:01,840
number equal to what one or exactly greater than whatever the initial ticket that we save to the database

13
00:01:01,840 --> 00:01:03,990
has its version number.

14
00:01:04,000 --> 00:01:07,950
So we're going to expect that the first save is going to work as expected.

15
00:01:08,050 --> 00:01:16,320
We're then going to try to save the second batch ticket when we try to save the second fetch ticket.

16
00:01:16,320 --> 00:01:21,300
This thing is going to have an outdated version number because when we saved the first batch tickets

17
00:01:21,570 --> 00:01:24,600
it will have incremented the version number inside of our database.

18
00:01:24,710 --> 00:01:28,710
So when we tried to save the second one we're going to expect to see some kind of air something and

19
00:01:28,710 --> 00:01:34,050
says hey you can't say this you've got some out-of-date version number or something similar to that

20
00:01:35,420 --> 00:01:39,220
we're going to save the second patch ticket and expect an error.

21
00:01:39,270 --> 00:01:40,510
That's the idea.

22
00:01:40,710 --> 00:01:45,860
So let's get to it step number one create a ticket and save it.

23
00:01:45,940 --> 00:01:55,610
They'll make a ticket using the ticket dot build method and I'll give this thing a title a price of

24
00:01:55,610 --> 00:01:56,150
five.

25
00:01:56,830 --> 00:01:59,110
And then we are required to provide a user I.D. as well.

26
00:01:59,110 --> 00:02:02,950
I'll just give I.D. at 1 2 3.

27
00:02:02,960 --> 00:02:08,750
Next up we're gonna say that your database will do in a way ticket save.

28
00:02:08,880 --> 00:02:14,490
Now that ticket has been persisted into the database and in theory when we saved it Mongoose and more

29
00:02:14,490 --> 00:02:19,640
specifically the update if current plugin should have assigned to some kind of version property to it.

30
00:02:19,880 --> 00:02:25,770
So inside the database there's now a record that says Here is the ticket as a version of 0 or 1.

31
00:02:25,770 --> 00:02:29,060
Again whatever the default version number is.

32
00:02:29,090 --> 00:02:35,860
So now going to fetch that ticket out of the database twice so I'll do a first ticket.

33
00:02:36,080 --> 00:02:45,340
But we call it first instance and that will be and a weight ticket that find by I.D. And we're going

34
00:02:45,340 --> 00:03:00,270
to find a ticket dot I.D. then second instance a weight ticket that find by I.D. like so now we're going

35
00:03:00,270 --> 00:03:05,150
to make a change to a first instance and to second instance will then save the first instance.

36
00:03:05,190 --> 00:03:06,740
And that should work as expected.

37
00:03:06,810 --> 00:03:10,440
Say the second one and we should see some kind of error.

38
00:03:10,520 --> 00:03:16,890
So here's my change to both the tickets I'll say first instance I'll do a set and I'll update the price

39
00:03:16,890 --> 00:03:22,730
to 10 you'll notice I'm once again getting it in error right here because when we do the fine by I.D.

40
00:03:22,730 --> 00:03:23,880
we might get back no.

41
00:03:23,930 --> 00:03:30,270
As usual I'm going to put an exclamation on there because again as usual we really want typescript to

42
00:03:30,270 --> 00:03:31,290
just not worry about that.

43
00:03:31,320 --> 00:03:36,740
If we fail to find that ticket I actually do want to see an error so we can fix up our tests then we'll

44
00:03:36,740 --> 00:03:40,440
do our second instance exclamation.

45
00:03:40,610 --> 00:03:45,510
We'll set our price to 15 Now here's the moment of truth.

46
00:03:45,510 --> 00:03:53,090
We're going to attempt to save these first tickets so await first instance exclamation dot save and

47
00:03:53,100 --> 00:03:54,940
that should go off as expected.

48
00:03:55,940 --> 00:04:00,930
Now we'll put down our second save right here and this one when we run it should result in an error.

49
00:04:00,980 --> 00:04:05,970
Right now we're going to throw the save in and we'll expect to see an error inside of our tests just

50
00:04:05,970 --> 00:04:10,340
to make sure that the test is working as expected and that in general all the stuff is working as expected

51
00:04:10,550 --> 00:04:11,840
around this versioning stuff.

52
00:04:12,030 --> 00:04:13,440
So I'll do it a wait.

53
00:04:13,610 --> 00:04:17,260
Second instance exclamation dot save.

54
00:04:17,450 --> 00:04:26,250
And that's it let's say this I'm not going to go backwards my terminal and I have closed the tests suites

55
00:04:26,280 --> 00:04:34,700
for my ticket service so I got to go into my tickets directory and do an NPM run test inside of here.

56
00:04:34,760 --> 00:04:38,030
We're going to see a lot of different tests run because there's also doing all of our root handlers

57
00:04:38,030 --> 00:04:38,940
and whatnot.

58
00:04:38,990 --> 00:04:41,670
I do see the tests for my ticket stuff though.

59
00:04:41,670 --> 00:04:43,490
OK it looks like I got one failure here.

60
00:04:43,550 --> 00:04:49,800
I'm going to scroll up a little bit and there we go exactly what we wanted to see.

61
00:04:49,870 --> 00:04:52,000
No matching document found for I.T..

62
00:04:52,000 --> 00:04:58,260
Blah blah blah with the first number of 0 when we're trying to update Rice.

63
00:04:58,430 --> 00:05:01,880
And you'll notice this error came from the second save.

64
00:05:01,900 --> 00:05:07,710
So the second instance right here has an outdated version property has the incorrect version property.

65
00:05:07,800 --> 00:05:11,900
Now even though this version property is outdated it's still kind of simulates what's gonna happen inside

66
00:05:11,900 --> 00:05:16,130
of our actual application where we might eventually try to save a document with a version that's too

67
00:05:16,130 --> 00:05:18,110
far into the future.

68
00:05:18,230 --> 00:05:19,660
So this right here is excellent.

69
00:05:19,670 --> 00:05:24,920
It means that this optimistic concurrency control stuff is working as expected.

70
00:05:25,020 --> 00:05:29,730
Now we really just have to fix up the test and make sure that we somehow say that we expect that this

71
00:05:29,730 --> 00:05:31,040
thing to go wrong.

72
00:05:31,250 --> 00:05:36,660
Now just you know just does have some built in matches to help us expect that something is going to

73
00:05:36,660 --> 00:05:37,560
throw an error.

74
00:05:37,560 --> 00:05:43,340
It has a matter of expect some function to throw.

75
00:05:43,350 --> 00:05:44,540
So we could do that in theory.

76
00:05:44,610 --> 00:05:48,730
But I found that there are some Interop issues between just and typescript.

77
00:05:48,930 --> 00:05:54,480
So I've found that this expectation right here does not quite work as expected if we wanted to really

78
00:05:54,480 --> 00:05:59,080
do this we would do something like this like so.

79
00:05:59,090 --> 00:06:02,000
But like I said I found that just doesn't work out too well with this.

80
00:06:02,070 --> 00:06:06,390
If you're watching this at some point in the future perhaps you can see this actually work as expected.

81
00:06:06,390 --> 00:06:08,600
But again I have not actually gotten this to work.

82
00:06:08,610 --> 00:06:14,450
So instead we have to get just a little bit creative here so because we do expect this thing to throw

83
00:06:16,310 --> 00:06:19,980
we're going to put in a try around that

84
00:06:23,410 --> 00:06:29,580
we're going to put in a couch and we're going to expect to get into a catch and if we get into the catch

85
00:06:29,580 --> 00:06:31,230
we're going to immediately return

86
00:06:34,080 --> 00:06:38,250
and because we should be entering the couch right there right after the throw a air manually.

87
00:06:38,260 --> 00:06:43,000
So throw new air and I'll say should not reach this point.

88
00:06:43,150 --> 00:06:46,990
So if our test is working as expected when we run this line of code right here we're going to throw

89
00:06:46,990 --> 00:06:52,480
an error that's going to cause us to enter the catch statement we should return automatically and when

90
00:06:52,480 --> 00:06:55,620
we return we will not get to that error.

91
00:06:55,750 --> 00:06:59,770
If this line of code does not throw then we're going to skip over the catch and we're going to get the

92
00:06:59,770 --> 00:07:03,870
error that's going to throw the air and that's going to cause our test to fail.

93
00:07:03,880 --> 00:07:08,410
Now one other little gotcha if you're going to use this pattern right here just cannot really figure

94
00:07:08,410 --> 00:07:12,180
out the async await situation here I can't really figure out when our tests are all done.

95
00:07:12,190 --> 00:07:13,630
When we call return right here.

96
00:07:13,630 --> 00:07:16,630
So you just help types you me to help just out.

97
00:07:16,630 --> 00:07:23,190
We have to receive a callback to our actual test function right here of done done is a function that

98
00:07:23,190 --> 00:07:28,110
we should invoke manually if we want to specifically tell just that we are done with our test and that

99
00:07:28,110 --> 00:07:33,380
should not expect anything else to go on with our test so right when we return right here we're gonna

100
00:07:33,380 --> 00:07:35,820
also called Don and just very officially tell just.

101
00:07:35,940 --> 00:07:36,420
That's it.

102
00:07:36,420 --> 00:07:37,170
Test complete.

103
00:07:37,170 --> 00:07:40,390
Don't worry about anything else inside this test.

104
00:07:40,410 --> 00:07:45,180
So again all this stuff right here is just to work around the fact that right now just with that to

105
00:07:45,180 --> 00:07:48,400
throw matter doesn't quite work as expected.

106
00:07:48,440 --> 00:07:48,590
OK.

107
00:07:48,630 --> 00:07:51,230
So let's say this and see how we're doing.

108
00:07:51,470 --> 00:07:52,110
Flip back over

109
00:07:55,340 --> 00:07:57,590
and it looks like everything is passing now.

110
00:07:57,680 --> 00:08:01,910
Let's run just our ticket test file by itself just to save ourselves a little bit of time here so I

111
00:08:01,910 --> 00:08:07,790
can hit W to enter the watch menu then P to enter in the name of the file I want to run and we want

112
00:08:07,790 --> 00:08:09,940
to run the ticket test file.

113
00:08:09,980 --> 00:08:12,120
So let's put in a better ticket.

114
00:08:12,140 --> 00:08:16,670
Oh they all say ticket inside of it I guess I guess I have to use a bit more.

115
00:08:16,720 --> 00:08:17,390
Oh yeah.

116
00:08:17,410 --> 00:08:23,100
I have to use all bit more specific button that lets do ticket dot test that's better.

117
00:08:23,140 --> 00:08:24,730
Now we're just running that one test.

118
00:08:24,750 --> 00:08:25,800
Very good.

119
00:08:25,800 --> 00:08:31,430
And as usual let's try to make it fail just one time here so I'll try commenting out the oh wait it's

120
00:08:31,430 --> 00:08:32,680
like an instance save.

121
00:08:32,930 --> 00:08:34,180
I'll say the file.

122
00:08:34,550 --> 00:08:35,330
And there we go.

123
00:08:35,330 --> 00:08:39,320
Looks like if it doesn't throw an error we do in fact end up getting to that error at the bottom and

124
00:08:39,320 --> 00:08:42,340
the tests fail.

125
00:08:42,350 --> 00:08:43,430
ALEX Good.

126
00:08:43,460 --> 00:08:45,440
So this is pretty fantastic stuff.

127
00:08:45,440 --> 00:08:50,060
This means that we can now be really sure that when we save a record if we save it successfully we are

128
00:08:50,060 --> 00:08:54,320
saving it essentially in the correct order and we're not working on some kind of stale data.

129
00:08:54,440 --> 00:08:58,910
And in the instance of our order service more processing events this is also going to make sure that

130
00:08:58,910 --> 00:09:01,520
we are processing events in the correct order.

131
00:09:01,560 --> 00:09:05,610
There is one other very quick test I would like to write in the next video so quick pause right here.

132
00:09:05,610 --> 00:09:06,370
I'll see you in just a minute.