-: In the last section,
we were able to override our default start command
to run our tests.
We've got Docker Run, we attach a standard-in
and psuedoterminal to that container that gets created.
We've got the ID, and then the override command.
When we run that, we get the output
that we usually see when we run a test suite.
I can then hit enter to refresh the test,
and yeah, it looks like everything is looking okay here.
However, (chuckles), you're going to very quickly
see that we are going to run into the exact same issue
that we've been trying to solve in the last
couple of sections as well.
If you open up your code editor,
I want you to find the SRC directory,
and then inside there, look for the app.test.JS file.
Inside of here, you'll see an it-statement.
So this is the actual test that is currently
being executed inside of our test suite.
I want to try making a modification to this file.
So, I'm going to highlight this it-statement
right here, the entire thing.
I'm going to copy it, and then I'm going to paste it
down right underneath it, and finally,
I will save the file.
If we then go back over to our terminal,
you'll notice that the test suite did not rerun,
and it still thinks that there is only one test.
You can try hitting enter to rerun the test suite
and it sticks at one test.
So, I bet you can kind of guess
what's going on here.
We've got a container that's been created
specifically to run some tests.
When we created that container,
we essentially took a snapshot of all of our
working files and folders,
and put that inside the container.
So, this very temporary container that we've made
just to run our tests, does not have all that
volume stuff set up. That is the issue.
And so, without any of those volumes set up,
we are using old and outdated files
inside of our container.
And any changes we make to our test suite
will not be reflected inside there.
So, in this section, we're gonna take a look at
one or two different ways that we can possibly solve this.
Now, we certainly could use a very similar approach
of setting up some volumes in the same way
we just did inside of our Docker Compose file
a moment ago.
So we can setup a second service inside of here.
We can assign some volumes to it,
and the entire purpose of that service
would be to run our test suite.
Now, that's definitely a way that we're going to go,
we're definitely going to give that a shot.
But, I first want to show you
a slightly different approach.
One in which we will not create a second service
inside the Docker Compose file.
So, let me show you this second approach first.
All right, I'm going to stop the running test suite
by hitting control + c.
And then I'm going to bring up our
Docker Compose instance with Docker Compose.
All right, so that has created,
well, in just a second here, there we go.
So that creates our single container
that is running our application.
Now, one possible way that we can solve
this issue with our test suite is,
rather than making a second service inside
the Docker Compose file, we could instead,
attach to the existing container that is created.
When we attach to it, we can then execute a command
to start up our test suite inside there.
And that will give us access to a container
that already has all this volume mapping set up.
So, let me show you how to do that.
I've got my Docker Compose container
running right here.
I'm going to open up a second terminal window.
And then inside of here, I'm going to get the ID
of our running container with Docker ps.
So, here is the ID of our running container.
So we can attempt to execute a new command
inside this container with Docker exec-it.
I'll put that ID down, and then the command
that we're going to execute will be npm run test.
So, essentially what we're going to do here
is reuse the existing container we have.
We're gonna start up our test suite inside there.
So I'll run that, and low and behold,
our test suite appears.
It looks like it now correctly recognizes
that we have two tests.
And if I go back over to my code editor
and find that app.test.JS file again,
I can delete that second it-statement.
So, I'll highlight the second one right here,
I'll delete it, and I'll save the file.
Then, we I go back to my terminal,
you'll notice that it automatically updated
and it's back to thinking that we've only got
one test inside there. Perfect!
So this is definitely a solution that works.
However, this is not necessarily the best solution.
Because if you are developing this application,
it's going to require you to start up Docker Compose,
then get the ID of that running container,
and run that Docker exec command.
Which is kind of hard to remember
off the top of your head.
So, this is definitely a solution,
but I don't think it's necessarily as good
as it possibly could be.
Now, let's take a quick pause right here,
we're gonna come back the next section,
and we're gonna try a slightly different approach
where we will add a second service
to our Docker Compose file.
The second service will be responsible
solely for running our test suites.
So, quick break, and I will see you
in just a minute.