-: In the last section,
we were able to start up our test suite separately
using Docker Compose.
This new container definitely respects
the volumes that we set up.
So any time that we change our project files or folders,
the test suite is going to see the change to those files
and automatically rerun,
which is definitely ideal.
However, you'll notice that we've still got
this kind of interactive menu right here.
It would be really great to be able to press P, T, or Q
to filter by file name, test name,
or essentially just work around
with the test suite a little bit.
But we can see that if we hit Enter here,
or P or Q or T, W, whatever it might be,
none of this input that we're adding into our terminal
is getting sent over to the running test suite.
So quick reminder on why that's occurring.
Here's a diagram of what's happening right now.
We've got our test container and the web container.
Both of those different containers
start up with a primary command.
For the test container, it's npm run test.
And for the web container, it's npm run start.
Anytime a process is created inside these containers,
it automatically gets a connection
to stdin, stdout, and stderr.
And as a reminder,
stdout, stdin, and stderr are all process-specific.
So every different process inside this container
has its own instance of stdin and stdout.
Now, we are currently typing in our terminal,
but there's nothing in place that is taking our text input,
like the keys we are pressing,
and automatically forwarding that input
over to stdin of the test container.
That would be ideal,
but it's not set up to do that by default.
And unfortunately, using Docker Compose,
we cannot easily set that up.
So let's try taking a slightly alternate approach here.
Let's try creating a second terminal window,
and in that terminal window,
we're going to run the docker attach command.
Remember what docker attach does.
With docker attach,
we can forward input from our terminal
directly to a specific container.
Let's try that out and see if we can't
kind of get that connection to the test suite
and be able to hit P, Q, T,
all those different things to manipulate the test suite.
All right, so I'm gonna open up a second terminal window,
and inside of here,
I'm gonna get the ID of that running container
with docker ps.
So here's the ID of the container.
Make sure you've got the one for npm run start.
I'll then try running docker attach,
and then I'll put that ID in.
So again, remember what docker attach does.
We are attaching to the stdin, stdout,
and stderr of the primary process inside that container.
So in theory, if we type something into our terminal,
that input will be sent to stdin on that primary process.
So let's see what happens.
I'll run that command.
And then it looks like my cursor
is just kind of hovering here,
so it feels like something is going correctly.
I'll try putting in P, Q, T, W, anything,
and it looks like,
well, it's not quite working as we expect.
Okay, so let me cut to the chase here.
Unfortunately, this is as good as it gets
with the Docker Compose solution for running our tests.
When we use Docker Compose,
we're not going to be able to manipulate our test suite
by entering P, T, Q, any of these special commands.
With Docker Compose,
this output right here is essentially
as good as it's going to get.
But I still wanna show you why that is.
So I wanna give you a little bit of a background here
and kind of apply some of the knowledge
we picked up earlier in the course about Docker
to understand why we are not going to be able to attach
directly to that container and enter in commands
and have them be affecting that running test process.
Okay, so kind of a deep-dive here, but let's do it.
So clearly, when we enter in additional text here,
it is not at all manipulating the test suite.
I wanna open up a second, or now, a third terminal window.
And inside of here,
we're gonna start up a shell instance
inside that running container,
and we're going to explore
some of the different running processes.
So I'm going to again do docker ps.
I'm going to get the ID of that container.
And I'll do, this time,
docker exec -it, the id, and then sh.
So remember what this does.
This is going to run a new command
inside the container with this ID.
With -it right here,
we are starting up a connection to stdin
on this new command that we are going to run.
And then sh over here on the very end
is gonna start up essentially a new shell
or kind of a command prompt inside the terminal.
Shell is very similar to Bash or Z shell, if you use that.
It's essentially just allowing us
to enter some commands directly into the container.
So I'm gonna run that.
You see that we get our command prompt right here.
And then we're going to run ps,
which is going to print out all the running processes
that we have going on inside the container.
So this is the reason why docker attach
did not quite work the way we expected.
Notice how we have a PID right here of 1
for the command npm.
We've then got a separate process running
for react-scripts start
and yet another PID for some other script's start thing
right here.
All right, so why is the text that we're entering
into the attached window over here not showing up?
Well, that all comes down to the different processes
that have been created inside the container.
You see, when we run npm run test,
we're not actually running directly npm run test.
In reality, what is running is the process npm.
And then npm looks at the additional arguments
we are providing, specifically run test,
and it uses those additional arguments to decide what to do.
So npm is going to eventually start up a second process
that is actually running our tests,
and that is one of these two right here.
I'll be honest, I don't actually know which one it is.
It's essentially just one of the two.
And so we might imagine that,
hey, let's just say it's this one right here.
That's the process that is running our test suite.
So we can kind of imagine
that there's a second process in here called start.js.
And this is the process
that is actually executing our test suite
and receiving commands over stdin
to understand when to filter down the test suite
or rerun them or whatever it might be.
The problem is that when we run docker attach,
we always attach to stdin
of the primary process of the container
with the process ID of 1.
And so that's always going to be the direct npm command.
But it's not the npm command
that is in charge of receiving those key presses
and interpreting all those kind of different options we have
of the P, T, and Q, and Enter right here.
It's the secondary process that was started by npm.
And so ideally, to be able to interact with that test suite,
we would want to attach to that other command
or that other running process.
But unfortunately, with docker attach,
that is just not an option.
Anytime we run docker attach,
we are always getting a handle on the primary process,
not the secondary one over there.
So, like I said,
unfortunately, as far as the test suite goes,
this is kind of as good as it gets.
We can either execute Docker Compose
to start up our tests inside of a second container.
Now, that's definitely convenient,
because we just have to run Docker Compose
and boom, we get all of our tests running.
But the downside to this approach
is that we do not have the ability
to kind of manipulate the running test suite
with the P, T, and Q shortcuts.
That's one option.
The other option
is to have just the single running container,
so that primary container of web right here,
and then we can run the docker exec command
to start up our test suite inside there.
The benefit to that
is that we can manipulate the test suite,
but as you saw, the downside was that we had to memorize
that docker exec command
and we also had to get the ID of the running container.
So, like I said, at the end of the day, two solutions here.
Neither of them are really 100% ideal,
but at least you can pick one of the two
that you like a little bit more to run your tests
if you decide to do so.
Now, the last thing I wanna mention here
is that there are definitely test suites out there
for other languages or even other JavaScript test suites
besides the one we are using
that do not actually have
this kind of command line interaction,
where you press in these commands
and it manipulates the test suite in some fashion.
There are definitely other test suites out there
that you just run 'em and that's pretty much it.
They just run, and you don't manipulate them in any fashion.
So it's definitely not necessarily
the worst thing in the world
that we can't kind of get a handle on this thing.
It would be nice if we could,
but unfortunately, we just can't.
So that's pretty much it on testing.
So let's take a quick pause right here,
and we'll continue in the next section.