In this video we're going to take a look at the different kinds of tests we're going to try to write
out for the different services inside of our ticketing project.
So again we're not going to focus too much on testing or trying to launch multiple services together
and try to test how they interact.
Instead we're going to try to look at each service individually and test them one at a time.
So I want to show you the different kinds of tests we're going to write as we're looking at say just
the auto service by itself.
The first kind of tests are we're going to write out is going to try to test basic request handling.
So for example we might want to try to make sure that if we make a request to our service to sign up
for something then perhaps we should get back a response with a cookie that has a just on web token
inside of it or we might want to try to assert that we write some data into our Mongo DB database.
So this is the first kind of test we're going to write we're going to make sure that we can issue a
request to the service and then make sure that it gets handled some in some very particular fashion.
The second test we're going to write is going to be more of a unit test style approach.
So the second test we're gonna write might take a look at a very particular model inside of our app
and try to test some functionality around it.
This is not very relevant for the auto service because our user model right now is very simple in nature
but some of these services that we work on later will have models that are a little bit more complicated.
And so we are going to wants to write some tests around them and make sure that they function in a very
particular way.
So again the second kind of test we're gonna write is going to take a look at individual models and
just try to make sure that they have some particular piece of functionality the final kind of test that
we're going to write is going to handle the receiving and emitting of events inside of our service at
present are off service is not sending out or receiving any events and we haven't even discussed event
handling inside this community's environment yet.
So we're not going to really worry about testicle number three either for the auto service but for our
later services we put together we will be writing out some code to make sure that we can receive incoming
events to make sure that they get processed in some particular way and to make sure that we can issue
events or send events to the outside world as well.
So again those are the three kinds of tests that we're going to be focusing on test gold number three
right here emitting and receiving events is how we are really going to accomplish simulating different
services working together.
So even though we are not going to directly at launch say in orders and ticketing service at the same
time and try to test them together this idea of testing events or receiving them any minimum is very
similar in nature and it will achieve a very similar goal.
All right.
One last thing.
How are we going to actually execute these tests.
In other words at a very practical level when I say to you.
Okay let's go and run our tests.
How do we do that.
How do we actually execute our tests at all.
Well we're going to take a very simple indirect approach.
We're going to run all of our tests directly at our terminal.
We're not going to Docker.
We're not going use coordinators or anything like that.
So when I say let's go run our tests we're going to pretty much go over to our terminal and run a command
like NPM run test that's going to start up our server on our local machine or individual service and
then tried to run some number of tests against it.
Now this has a very strong implication.
This is really implying that our local environment is capable 100 percent of running each of these services
and that probably makes a lot of sense right now.
Think about our auth service what dependencies or what software do we need to have installed on our
local system to run the service.
Well we pretty much just need no J.S. and a copy of Mongo DB.
That's all we really have to have installed on our local system to run the service.
But in the future you might be working on way more complex projects projects where your services have
way more dependencies.
In other words at some point in time the future you might be trying to test a service that requires
you to have a very particular operating system or a very particular and very complex and hard to run
hard to set up database.
So even though this approach is going to be just fine for this current application in the future it
might not work out so well.
So I am going to show you some way that we can still run tests very easily.
Let's a little bit more complex in nature but it can also handle way more complex setup requirements
if not that makes sense right now.
Don't sweat it.
Keep in mind I'm going to give you a quick guide on how to handle more complex testing in the future.
OK.
So if all this in mind I think we've got a good overview on what we're doing so we can take a quick
pause right now and then actually get down to the nitty gritty.
What are we really doing here.
What code are we really writing to test out our all service.