Our OTT service is now looking pretty good.
We've got all the custom error handling middleware as roots.
It's all coming together but you might recall that when we first started this project I had mentioned
that we were going to really put a good focus on testing at this point.
We have not done any automated testing.
We have done testing using postman but no automated tests.
So naturally we're going to start to fix that up inside the Section.
We're going to first begin with a quick overview of how we handle testing in a micros services type
environment.
The first big thing that we need to understand is that testing with micros services is really a big
question of what the scope of our tests are going to be.
So we're going to write out some code that is going to test our app in an automated fashion and we need
to decide exactly what we are trying to test.
There's a wide variety or a wide spectrum of different things we can try to test inside of one single
test the list I have right here of four different things is by no means an exhaustive list.
I just want to point out that there are many different things we can try to test inside of a single
test go so we might first decide at the most basic level to test a single piece of code in isolation.
And so an example of that would be something like a middleware.
This would be a very traditional style of test something you might refer to as a unit test the next
level of complexity or the next kind of larger piece of scope would be to test how different pieces
of code work together.
An example that would be maybe if we tried to simulate a request flowing through some different middleware
together and then eventually off to a root handler.
Now as I go through these two notes right here it might make a bit more sense to kind of visualize this.
So I put together a little diagram of more or less what our application looks like right now.
And some parts to represent what it might look like in the future as well.
So we do not yet have an orders ticketing or payment service but we will at some point so this first
piece of scope right here would be if you're just trying to test one single piece of code that might
be like if we wrote out a test to just take a look at the require auth middleware and figure out whether
or not that thing is working correctly the next larger piece of scope would be to test multiple piece
of code working together.
And so I'd be kind of like if we had a request coming in and had it float through the require auth middleware
and then up to some sign up root handler.
Now in this case we're not going to ever wire up require auth and sign it together.
I just mean to suggest that we could have a test that spans across different pieces of code the next
larger piece of scope would be to test how multiple components work together.
Now don't use the term component here.
I'm not referring to react.
I'm talking about different programs so we are running inside of our app.
So for example that would be if we were trying to test how our auth service interacts with Mongo DV
or how our auth service interacts with the event plus.
And then finally the largest piece of scope the largest thing we can really test in one go would be
to test our different services work together.
So for example we might try to lunch our order service and the ticketing service at the exact same time
and then have one emit some kind of event and then expect it to be received by the other service in
for it to be processed in some very particular way.
So again we really need to think about the scope of every test that we start to write out.
Now of course when we start to look at this list you might say or trend towards this item down here
at the bottom you might say oh yeah let's just test how all these different services work together because
that kind of simulates reality.
Well that might make a lot of sense when we say it we might want want to write tests like that but unfortunately
the reality is that writing tests like this is very very complicated inside of a micro services environment.
If we want to test how the order service and the ticketing service interact with each other we need
to think about how to construct some kind of environment quickly and cost effectively to actually test
this stuff.
So I mean at a very practical level how would we do that.
Would we launch some kind of test Cuban 80s cluster and then launch the order service and ticketing
service inside there.
How would we somehow issue request of these things.
How would we somehow assert the results of any requests we make.
It's just a very complicated thing that starts to get really challenging when we start to figure out
or try to figure out how multiple services work together so that mind we are not going to focus too
much on how we can test different services working together.
Instead we're going to try to test these different services more or less in isolation so let's take
a pause right here.
When we come back next video I'm going to show you the different kinds of tests that you and I are going
to focus on writing inside of our different projects.