Now the first step is to test your website.
Now, when it comes to testing websites,
we actually have two approaches,
of which we only saw one in this course.
You can of course test your website manually.
But you can also test it in an automated way.
Now, when we speak about manual testing,
it really just means what it sounds like.
You test your website yourself,
you test for common user behaviors.
Also, maybe for a couple of strange behaviors
users might have for a couple of potential bugs.
You want to therefore test for such a rare,
but still possible scenarios as well.
And if possible, you might want to invite
a couple of friends or other people who also help you
test your website, because it turns out
you're pretty bad at finding your own bugs.
Other people often are way better at that.
Now that's manual testing.
And that is what you'll always do,
no matter which website you build.
Now, you can enhance this by also adding automated testing,
which is a bit more advanced though.
Hence, it's also not covered in this course
and not the focus of this course.
You could build entire courses
on just that topic alone instead.
Because the idea with automated testing is that you actually
write code, scripts that test your code,
your website automatically.
So you write code that tests code. Yes, this is a thing.
And with that, you can then write code that tests
individual building blocks of your site,
or entire user flows.
And of course you would typically try to write a lot of
testing scripts so that you test all the key features and
behaviors on your site, and the advantage of such automated
tests, then is that whenever you change something
about your website, you don't have to test it all
manually again. Though you should always also test manually.
But you can also then just run
your automated testing scripts.
And they will do a bunch of tests for you,
way more comprehensive and quicker
than you would be able to do it.
But again, it's an advanced topic.
Therefore, I wanted to mention it here
because you should be aware of it,
but we'll not dive into it here.
Now the two example sites I provided to you should work,
but of course you can also test it.
I mean the static site is fairly easy to test.
You can look for typos here and that's it, I guess.
For the dynamic-site what we can do is,
we can open this integrated terminal here, and navigate
into this dynamic-site folder with CD dynamic-site,
and then run NPM install.
The first time that we got this project,
because the node modules folder doesn't exist yet,
as you learned.
And then you can run NPM Start to Start, a little script
which I set up and packaged on Jason,
which starts the server with help of nodemon.
And then you can visit local host 3000, though actually
you need a database server to be up and running a
MongoDB database server.
Otherwise running NPM Start probably already crashed.
So you have to install MongoDB and start a
MongoDB server locally on your system,
as we did it before in this course as well.
And once you've got that, you can visit local host 3000.
And now you can also click this Like button,
and you'll see a Like counter go up here.
And I also log the time when this page was last liked.
That's the dynamic part of this site.
So I think it works.
And hence, I'm happy with how we tested this.
Of course, bigger sites like the Online Shop
should take more testing and you very likely will
be able to find some room for improvement there.
But for this page it's done,
but we got more steps to go through of course.
Testing our website is just one part of this first step.
The second part is to prepare our code for deployment.
And here I also mention a feature called
environment variables, which I also want to come back to.
Now, what do I mean with preparing our code for deployment?
With that I mean that you will, for example,
want to remove and replace all dummy values
that you might have somewhere in your code,
with correct concrete values.
You also want to replace any testing data or keys,
with real data and keys.
And specifically you might, for example,
remember that for the Online Shop
we used Stripe and there also the Stripe API key.
And I did mention in that core section
that we were in testing mode. You, for example,
would want to switch to the real mode in Stripe.
For which you need to activate your account
and use the API key connected to this real mode,
before you proceed with deployment.
And of course, this would mean that you take the API key
for a non testing mode,
and put that into your code
instead of the testing mode API key.
But when it comes to having different values
for development and deployment. As we, for example,
would have it with the API key used by Stripe.
But as we, for example, will also have it with
the MongoDB database URL,
because we'll use a different hosting provider
for our deployed website than we do in local development.
In such cases, swapping these values and codes
all the time can get very annoying and error prone,
because you manually have to update the code
when you want to move it onto a remote machine.
And then you have to update it again,
if you want to develop on your local machine again.
You constantly have to switch between values
possibly in different places of your code.
That's where a feature called environment variables
comes in handy. Environment variables is
a feature that exists,
not just in NodeJS, but in any programming language.
All programming languages have a feature like this.
And the idea is that you can use a variable
in a place where you need a value. So, for example,
in a place where you need the API key
or the MongoDB database URL.
So you use a variable here
and you use a special kind of variable,
which is not set somewhere in your code.
But which instead, is set in the environment. For example,
on a remote machine that will host your code.
And that is then injected into the running website code
once it starts running on that remote machine,
or whichever machine it runs on.
So it's a variable, that's not set in the code,
but in the environment,
but which will be available in your code.
And for example, here,
if I quit this development server here.
We could replace this MongoDB URL
with such environment variable.
For this, I'll add a regular variable here,
mongodbUri, or mongodbUrl could be the name.
It's basically the same thing.
And here we could have a default value of
mongodb://localhost:27017,
which is our local development value.
And we can then of course use the mongodbUrl
variable down here.
But with that, we're not using an environment variable,
we're using a regular variable.
But now we can add an if check to override this value,
if a more specific environment variable
with such a URL is set.
And for this in NodeJS,
and it will be different in other programming languages,
but the documentation of those languages
will tell you which code is correct.
In NodeJS you get access to these environment variables,
which are injected by the environment
into this running code,
by accessing the global process object.
This is not defined by us,
it's made available by NodeJS instead.
And on process, you have a env property for environment.
And that is an object which contains
all the environment variables
that are exposed to your NodeJS program by the environment.
Therefore, of course you have to know
which variables will be exposed.
But since you will deploy your code
to some remote machine on your own,
and you can then configure that remote machine
to expose and provide certain environment variables.
You as a developer can decide which
environment variables you want later.
And here I'll add a MONGODB_URL environment variable.
And if that is set, if this is truth, if that is found.
Then I'll set mongodbUrl
equal to that environment variable value.
Now in local development, for example, this will not be set.
So in local development, this will still be used.
But later once we deploy this,
we will ensure that this environment variable
is set in the environment,
and therefore then this will be used instead.
And hence, will connect to the server
with that value stored in this environment variable,
instead of the default variable here.
Now, still as mentioned,
we can run NPM Start here on the local machine,
because this is not set. Hence we don't overwrite it,
instead we use the starting value.
But now we're using an environment variable here
and we don't have to swap code manually.
Instead, we can just configure
the environment appropriately.
I'll come back to environment variables later.
But that is what you should know about them right now.
In the front end code this does of course matter,
because there all the code is
evaluated in the browser anyways.
And therefore there we got no code
that would run on a remote machine,
and in the remote machine environment therefore.
Now last, but not least, there's always one specific aspect
you should be aware of.
If you have a website where users can upload something.
Like in the Online Shop
where the product images could be uploaded.
In such cases, we stored the uploaded files
in our project folder in the end.
And we serve them from there, and that can be fine,
but you might want to consider using a cloud storage
provider for that instead. For example, Cloudinary.
And that's really just one example.
There are dozens and hundreds of alternatives probably.
But Cloudinary is a service provider,
like Stripe was a service provider.
Which does not offer payments,
but which instead offers hosting or storage
of files and videos. Images and video files typically.
You can learn more about them on their website,
and they give you tools for automatically uploading.
So therefore, forwarding files
that you got on your server to their servers,
so that they will store it for you.
And they then give you URLs,
which you can use in your templates,
so that the files are requested directly from Cloudinary.
And then you don't have to store them on your own server,
which can be bad for performance,
for your hard drive which could run out of space, and so on.
Now it costs money. Most providers cost money,
though they also got a plan with which you can get started
for free.
And it is just something you should think about anyways.
Not a must do, but something that's worth a closer look
if you're building a bigger website
where users can upload files.
Then using such a third party cloud storage provider
might be a good idea, to offload work from your server,
and to get various other benefits
like automatic image optimization, for example.
But with that, these are some main aspects
you should keep in mind
when preparing your website code for deployment.
And therefore lets move on to the next step.