1
00:00:01,060 --> 00:00:02,830
Our OTT service is now looking pretty good.

2
00:00:02,830 --> 00:00:05,550
We've got all the custom error handling middleware as roots.

3
00:00:05,590 --> 00:00:10,030
It's all coming together but you might recall that when we first started this project I had mentioned

4
00:00:10,030 --> 00:00:13,510
that we were going to really put a good focus on testing at this point.

5
00:00:13,540 --> 00:00:15,690
We have not done any automated testing.

6
00:00:15,760 --> 00:00:19,030
We have done testing using postman but no automated tests.

7
00:00:19,030 --> 00:00:22,080
So naturally we're going to start to fix that up inside the Section.

8
00:00:22,300 --> 00:00:26,800
We're going to first begin with a quick overview of how we handle testing in a micros services type

9
00:00:26,800 --> 00:00:28,570
environment.

10
00:00:28,600 --> 00:00:33,100
The first big thing that we need to understand is that testing with micros services is really a big

11
00:00:33,100 --> 00:00:36,760
question of what the scope of our tests are going to be.

12
00:00:36,820 --> 00:00:41,050
So we're going to write out some code that is going to test our app in an automated fashion and we need

13
00:00:41,050 --> 00:00:44,890
to decide exactly what we are trying to test.

14
00:00:44,920 --> 00:00:50,020
There's a wide variety or a wide spectrum of different things we can try to test inside of one single

15
00:00:50,020 --> 00:00:55,690
test the list I have right here of four different things is by no means an exhaustive list.

16
00:00:55,730 --> 00:00:59,810
I just want to point out that there are many different things we can try to test inside of a single

17
00:00:59,810 --> 00:01:07,260
test go so we might first decide at the most basic level to test a single piece of code in isolation.

18
00:01:07,280 --> 00:01:09,670
And so an example of that would be something like a middleware.

19
00:01:09,770 --> 00:01:15,160
This would be a very traditional style of test something you might refer to as a unit test the next

20
00:01:15,160 --> 00:01:19,780
level of complexity or the next kind of larger piece of scope would be to test how different pieces

21
00:01:19,780 --> 00:01:21,210
of code work together.

22
00:01:21,250 --> 00:01:25,560
An example that would be maybe if we tried to simulate a request flowing through some different middleware

23
00:01:25,590 --> 00:01:28,780
together and then eventually off to a root handler.

24
00:01:28,780 --> 00:01:32,620
Now as I go through these two notes right here it might make a bit more sense to kind of visualize this.

25
00:01:32,950 --> 00:01:37,300
So I put together a little diagram of more or less what our application looks like right now.

26
00:01:37,450 --> 00:01:40,790
And some parts to represent what it might look like in the future as well.

27
00:01:40,900 --> 00:01:47,030
So we do not yet have an orders ticketing or payment service but we will at some point so this first

28
00:01:47,030 --> 00:01:51,020
piece of scope right here would be if you're just trying to test one single piece of code that might

29
00:01:51,020 --> 00:01:55,940
be like if we wrote out a test to just take a look at the require auth middleware and figure out whether

30
00:01:55,940 --> 00:02:01,800
or not that thing is working correctly the next larger piece of scope would be to test multiple piece

31
00:02:01,800 --> 00:02:02,860
of code working together.

32
00:02:02,880 --> 00:02:08,880
And so I'd be kind of like if we had a request coming in and had it float through the require auth middleware

33
00:02:08,940 --> 00:02:11,460
and then up to some sign up root handler.

34
00:02:11,490 --> 00:02:15,420
Now in this case we're not going to ever wire up require auth and sign it together.

35
00:02:15,420 --> 00:02:22,220
I just mean to suggest that we could have a test that spans across different pieces of code the next

36
00:02:22,220 --> 00:02:26,580
larger piece of scope would be to test how multiple components work together.

37
00:02:26,690 --> 00:02:28,250
Now don't use the term component here.

38
00:02:28,250 --> 00:02:29,700
I'm not referring to react.

39
00:02:29,840 --> 00:02:33,770
I'm talking about different programs so we are running inside of our app.

40
00:02:33,770 --> 00:02:39,350
So for example that would be if we were trying to test how our auth service interacts with Mongo DV

41
00:02:39,920 --> 00:02:43,970
or how our auth service interacts with the event plus.

42
00:02:44,160 --> 00:02:48,930
And then finally the largest piece of scope the largest thing we can really test in one go would be

43
00:02:48,930 --> 00:02:51,630
to test our different services work together.

44
00:02:51,660 --> 00:02:58,540
So for example we might try to lunch our order service and the ticketing service at the exact same time

45
00:02:58,840 --> 00:03:03,900
and then have one emit some kind of event and then expect it to be received by the other service in

46
00:03:03,920 --> 00:03:07,390
for it to be processed in some very particular way.

47
00:03:07,390 --> 00:03:11,930
So again we really need to think about the scope of every test that we start to write out.

48
00:03:12,100 --> 00:03:16,660
Now of course when we start to look at this list you might say or trend towards this item down here

49
00:03:16,660 --> 00:03:20,830
at the bottom you might say oh yeah let's just test how all these different services work together because

50
00:03:20,830 --> 00:03:22,870
that kind of simulates reality.

51
00:03:22,930 --> 00:03:28,090
Well that might make a lot of sense when we say it we might want want to write tests like that but unfortunately

52
00:03:28,120 --> 00:03:34,990
the reality is that writing tests like this is very very complicated inside of a micro services environment.

53
00:03:35,290 --> 00:03:39,580
If we want to test how the order service and the ticketing service interact with each other we need

54
00:03:39,580 --> 00:03:44,770
to think about how to construct some kind of environment quickly and cost effectively to actually test

55
00:03:44,770 --> 00:03:45,220
this stuff.

56
00:03:45,880 --> 00:03:48,730
So I mean at a very practical level how would we do that.

57
00:03:48,730 --> 00:03:53,860
Would we launch some kind of test Cuban 80s cluster and then launch the order service and ticketing

58
00:03:53,860 --> 00:03:55,290
service inside there.

59
00:03:55,300 --> 00:03:57,950
How would we somehow issue request of these things.

60
00:03:58,090 --> 00:04:01,690
How would we somehow assert the results of any requests we make.

61
00:04:01,690 --> 00:04:06,010
It's just a very complicated thing that starts to get really challenging when we start to figure out

62
00:04:06,010 --> 00:04:11,790
or try to figure out how multiple services work together so that mind we are not going to focus too

63
00:04:11,790 --> 00:04:15,330
much on how we can test different services working together.

64
00:04:15,330 --> 00:04:21,050
Instead we're going to try to test these different services more or less in isolation so let's take

65
00:04:21,050 --> 00:04:21,740
a pause right here.

66
00:04:21,770 --> 00:04:25,130
When we come back next video I'm going to show you the different kinds of tests that you and I are going

67
00:04:25,130 --> 00:04:27,470
to focus on writing inside of our different projects.