1
00:00:01,320 --> 00:00:01,590
All right.

2
00:00:01,590 --> 00:00:03,640
Time to do some manual testing here.

3
00:00:03,670 --> 00:00:08,100
What we're going to do is use postmen to manually create a ticket and then manually update it.

4
00:00:08,160 --> 00:00:11,480
So I've still got postman open right here inside a postman.

5
00:00:11,480 --> 00:00:15,020
The first thing we're going to do is make sure that we are still signed in to make sure that you're

6
00:00:15,050 --> 00:00:16,120
still authenticated.

7
00:00:16,130 --> 00:00:22,720
You can make a GET request to API users current user so when I send this off I see that I am logged

8
00:00:22,720 --> 00:00:24,520
in because there is an object right there.

9
00:00:24,610 --> 00:00:29,250
If you are not logged in it will say current user no instead to log back in.

10
00:00:29,290 --> 00:00:32,360
You can open up another tab inside a postman.

11
00:00:32,530 --> 00:00:40,180
You'll want to make a post request to API users sign up make sure you've got body raw Jason selected

12
00:00:40,210 --> 00:00:45,150
and then just enter in an email and password as soon as you sign up with an account you will then be

13
00:00:45,150 --> 00:00:46,770
considered to be authenticated.

14
00:00:46,830 --> 00:00:51,120
So come back over to this tab where you're checking your current user status send the request off and

15
00:00:51,120 --> 00:00:57,710
just make sure that you are signed in then finally will open up a third tab and inside of this third

16
00:00:57,710 --> 00:01:03,680
tab we're going to make a post request to API slash tickets we'll make sure we've got raw and Jason

17
00:01:03,690 --> 00:01:08,070
selected and we'll enter in some attributes for a ticket.

18
00:01:08,160 --> 00:01:15,050
So a title and a price once I've got that and I'll then send the request off and I should see something

19
00:01:15,050 --> 00:01:20,510
that says status to a one create a down here and I should see some attributes around the ticket as well.

20
00:01:20,510 --> 00:01:25,910
And now hopefully most critically we should be go back be able to go back over toward terminal and see

21
00:01:25,910 --> 00:01:33,320
some logging information around not only publishing and event but also receiving end event as well.

22
00:01:33,320 --> 00:01:39,110
So you'll notice that I get event published to ticket created that's for my ticket service and then

23
00:01:39,110 --> 00:01:44,090
for my order service I see message received on the subject of ticket created.

24
00:01:44,090 --> 00:01:46,250
And it was received by the orders service

25
00:01:49,520 --> 00:01:51,440
that's our ticket created events.

26
00:01:51,440 --> 00:01:53,670
Let's make sure that ticket updated works as well.

27
00:01:54,880 --> 00:02:00,030
So to do a updates we're going to once again on this tab where we just created a ticket.

28
00:02:00,040 --> 00:02:01,890
We're gonna grab the idea right there.

29
00:02:01,900 --> 00:02:09,060
The ticket we just created and we'll make a request to API tickets Slash.

30
00:02:09,100 --> 00:02:15,240
And then the idea of the ticket you just created will then adjust the price in some way dollar adjust

31
00:02:15,250 --> 00:02:21,870
my price to say about 10 instead I'll then send the request off we should once again get a status of

32
00:02:21,870 --> 00:02:24,900
two hundred OK and then see the updated record right here.

33
00:02:25,020 --> 00:02:27,880
And I've got a price of 10 very good.

34
00:02:27,980 --> 00:02:33,520
Now again as the real test back over to our terminal and we should see something that says even published

35
00:02:33,520 --> 00:02:39,560
you ticket updated and message received on ticket updated you will notice that the console logs here

36
00:02:39,560 --> 00:02:40,470
are out of order.

37
00:02:40,490 --> 00:02:43,690
That is only ok just because of the way scaffold works.

38
00:02:43,760 --> 00:02:47,090
Sometimes these console logs get reflected in a slightly different order.

39
00:02:47,180 --> 00:02:48,620
No problem whatsoever.

40
00:02:48,620 --> 00:02:53,000
At the end of the day the order service does not somehow magically predicting that this event is going

41
00:02:53,000 --> 00:02:54,970
to come over before it does.

42
00:02:55,210 --> 00:02:55,440
All right.

43
00:02:55,480 --> 00:02:58,360
Let's say that this is a good manual test.

44
00:02:58,360 --> 00:03:03,700
However has I mentioned this is where all those concurrency issues are going to start to become absolute

45
00:03:03,700 --> 00:03:08,470
first class citizens problems so we're gonna have to solve now that we've got this entire publisher

46
00:03:08,500 --> 00:03:11,770
and listener infrastructure setup to two pause right here.

47
00:03:11,770 --> 00:03:15,540
We're going to start to see some really weird behavior in the next video.