Instructor: So we've deleted everything out of
our test helper file, and our step one here is gonna be
to set up our testing environment to run
like a browser in the command line.
So what exactly does that mean?
Let's talk a little bit about that to start.
This first section right here is probably gonna be one
of the hardest that we're going through inside
of this spec helper.
So, let's tackle the hardest one first.
I'm gonna pull a diagram up on the screen to help illustrate
the challenge of what we're trying to do here.
So we're working on some code that eventually gets turned
into a file called bundle.js.
Bundle.js represents our entire application.
All of the code that we wrote plus the React Library
plus any other libraries that we pulled in.
It doesn't include anything like say mocha
or Chai or jQuery or anything like that.
Mocha or bundle.js solely represents our kind of
production application that we might one day push out
to the world online on a server
and let users actually poke around with it.
So when we make our bundle.js,
we usually are executing it inside of a browser, right?
Like we load it up inside of Chrome, it renders something
to the document, and it appears on the screen to us.
But when we write our specs and run them,
we're not tapping over to the browser
to run the specs.
We've always been going over to our terminal
and we rely upon the terminal
to run all of our specs instead.
So the first thing I wanna make really clear here is that
we've got two different environments
that we're running this application on.
On the one hand we've got the browser
which has all the things you would expect from a browser.
So it's got a window object that represents
kind of the browser of sorts.
We've got the DOM, we've got HTML elements,
we got all this great stuff available to us
when we're running inside of the browser.
But when we execute our specs from the terminal,
we don't have the benefit of any of that.
There is no browser inside of our terminal window.
There's nothing like window or document or event handlers
or even the DOM inside of the terminal.
The terminal is just the terminal.
That's all that's going on there.
And so this first little piece of setup
that we're going to do
is, we're gonna do a little bit of setup that's going
to help us out with setting up jQuery,
specifically jQuery,
to work appropriately at the command line
where it does not have access to the DOM
or any of these objects that it might expect to have.
So to help with this kind of implementation of the DOM
or the browser at the command line, we're gonna make use
of a library called jsdom.
And I'm only going to kind of in passing,
pull up some of the documentation
for some of these libraries that we're gonna use.
I do encourage you to maybe do a little bit of research
in each of them so you know what's going on
behind the scenes,
beyond just what we're gonna talk about.
So this jsdom library
really best summed up by this tagline right here.
It's a JavaScript implementation of the DOM
and HTML standards for use with node.js.
And node.js is really what we are executing
at the command line when we run our specs.
So in short, jsdom is a kind of emulation
or it fakes the DOM and HTML at the command line.
And so that's how we get away with simulating
or making our bundle.js and all of its dependencies think
that it's actually running inside of a browser
when in fact it's all running from the terminal.
So let's do a little bit of the setup related
to this first library.
The first thing that we're gonna do is import
the jsdom library.
So we'll import jsdom from jsdom.
Now we need to essentially create a fake HTML document.
That's the entire purpose of jsdom.
And then we're going to assign that to a global variable.
Keep in mind that in Chrome or any browser we're used to,
when we write JavaScript,
kind of the window scope is the global scope
and we refer to it with the window keyword.
When we're working with a node or a node environment
which we are with the terminal,
instead of using window, we use global instead.
So we're going to assign global.document.
And this is exactly equivalent to in the browser
assigning something to window.document.
And you may be familiar with window.document
and a html or JavaScript land.
So now we're going to create our fake DOM
and assign it to document.
So we'll say jsdom.jsdom.
So this is what's gonna create a HTML snippet for us.
And then we're going to put in here our fake tiny itsy bitsy
little HTML document.
So we'll write, doctype html html body
and then we'll close the body tag and close the HTML tag.
So this little bit of code right here is what initializes
and sets up our fake browser
for our use at the command line inside of our terminal.
We do that initial setup
and then we assign it to the global variable document.
So any library that we load up, so like say jquery
is a fantastic example,
is going to whenever it reaches out to say document
or window, and jquery is really gonna take for granted
that those variables are available
'cause it assumes that it's always running in a browser.
We're going to fake those variables out right here.
So when jquery boots up
it's going to get fake references to document.
We're going to also assign another fake property here
very similar to document.
This one's gonna be window.
And we'll get window from global.document,
which is basically this variable right here
that we just assigned .defaultView.
And so if these variable names are mystery here
or you're thinking to yourself,
where in the world did he get these variable names from?
I gotta tell you, I'm no master.
This is coming straight from the documentation.
So if you wanna figure out what exactly
document.defaultView is,
I recommend you check out the jsdom documentation.
So these two lines right here
are what does that kind of initial setup for us.
It does the initial setup of saying,
Hey we know that we're running at the command line.
We know that we're not really in a browser,
but we're gonna fake one out anyways.
So any library that depends upon the DOM existing
is gonna have something to hook onto.
So this is the,
a lot of discussion over two lines of code right here
and heck, we're not even done with it just yet.
But I do wanna spend a good amount of time on this
all the topics inside of this file,
and make sure that it's really clear what's going on
inside this test helper.
So with these two lines done,
let's go ahead and continue inside of the next section.