-: In the last section,
we got our Docker container to be aware of changes
that are made to our test files
by starting up our primary container with Docker Compose.
And then kind of piggybacking on that thing
using the Docker exec command.
So we ran Docker exec with the container ID
and we executed an PM run test inside there.
Again, I don't think this is a perfect solution
because it requires you to first get a handle
on the container ID.
So in the section,
I'm gonna show you a slightly different approach.
Now you might be thinking, "Steven
why are you showing us more than one approach?
Why didn't you just show us the second approach
to start with if it's so good?"
Well, the answer is that it's not the perfect solution.
So I'm gonna show you the second way of solving this
but again it's not quite a perfect solution,
just in my opinion.
So let's try putting this together
and you'll see exactly why.
Now I'm gonna find the terminal
that's running my Docker compose,
and I'm gonna stop it by hitting control C.
And then I'll flip back over to my code editor
and I'm going to open up my Docker compose dot YAML file.
So in the last solution we looked at,
we kind of piggybacked
on this existing service to run our tests.
So with this new solution
we're going to create a completely second service
inside the Docker compose file.
And its sole purpose is going to be to run our tests.
So to create a second service
I'm gonna add a new line inside of here
and I'm going to add in one level of indentation
and then I'll create the second service
with the name of "Tes", like so.
Now remember, in a YAML file
it's extremely important to make sure
that you get all of your tabbing and indentation correct.
So make sure you've got one indentation right here
right before "Tes".
And then for the second little option we're
about to push put in here,
you should have two indentations.
So to build this kind of test service
we're again going to kind of copy
some of the configuration you see right here
because we want to again,
build our container using the context
in the current directory using that docker file.
And we're also going to want to setup
the same volumes that we had before.
However,
we do not need to specify any ports this time around
because our test suite doesn't make use
of any ports whatsoever
'cause there's really no running server inside there.
So for "Tes", I'll specify my build
with a context of the current directory
and the docker file of docker file dot dev.
I'll then set up my volumes.
Remember we get a little dash in front of our volumes
because this essentially represents an array.
I'll set up a volume on node modules again
to kind of set up a placeholder there
and make sure we don't accidentally
override that directory or anything like that.
And then we'll also map up the current working directory
colon slash app.
And then finally, the last thing we need to do
is we're going to override the starting command used
when this "Tes" service is created
or the test container is created.
So we're gonna override that starting command
and we're gonna make sure that it starts with NPM run test
rather than the default NPM run start.
So to override a command
inside of a docker file we'll specify command
and then we can write out all the different parts
of that command in a set of quotes in a little array.
So we'll say NPM run test.
Now when I say little array
this technically right here
is not the same type of array that a YAML file array is
like that right there.
It's just a slightly different notation.
Okay, so that's it.
I'm gonna save this file.
So now whenever we run Docker compose up,
we're gonna startup one container
that's gonna be responsible
for hosting our development server
and the second container that is gonna be solely responsible
for running our tests
and rerunning any time
that any file inside of our volumes change.
So let's try starting these up now.
I'll go back over to my command line
and I'm gonna do Docker compose up
and I'm gonna add on a dash dash build to this as well.
Now technically we've not made any changes
to any of our files,
but sometimes when you add on a new service
it can be a little bit finicky.
So I'm just gonna throw on the dash dash build.
All right, so there we go.
So we have our test suite running.
You can kind of see the test right there.
And then we also see the message saying
that we can view our application inside the browser.
So we can now flip back over to our code editor
and attempt to make a change to our test file.
Remember, that's the SRC directory.
We're looking for app dot test dot JS.
So I'm going to change the thing
by again just copy pasting down the it statement,
I'll save it.
And then if you flip back over to your terminal
you'll see that our test suite has reran
and it now has the two separate tests.
All right, so again, this definitely works
but there is a little problem with this approach as well.
With the last approach
for solving the tests that we looked at
we had to remember the kind of ID of the container.
We had to remember the command
to execute our test suite inside there.
That was the downside to that approach.
The downside to this approach
is that we are getting all the output from our test suite
inside of the kind of login interface of Docker compose
and we don't have the ability to enter
any standard in output to that container.
So I can't hit enter to get the test suite to rerun.
I can't hit W to get any of the options
inside the test suite to appear or anything like that.
Now you might be thinking,
"Okay, like Steven, that's fine.
We could always try attaching directly to the container."
Well, that's definitely an option.
Let's take a quick pause right here
and we're in the next section.
We're gonna see if we can reuse
that Docker attached command,
that we looked at way long ago,
to attach directly to this container
and add in some custom input
by hitting enter or W or whatever it might be
to manipulate the test suite.
So quick break and I'll see you in just a minute.