Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
We already test our code all the time, or else we’d never know it was working! But we can get even smarter about that by automating the process.
Problems with manual testing
- Difficult to write effectively
- Impacts your actual program
- Hard to read
- Only a temporary fix
You can accomplish a lot of the same things more succinctly using automated tests.
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
When developing we're constantly
in the process of testing things.
0:00
We write code,
check that it does what we want, and
0:03
make sure nothing else
broke in the meantime.
0:06
As we're starting out we usually
just write some code and
0:09
then run it to see if it breaks.
0:12
For example, we might write a function
that adds three numbers together.
0:14
How do we know that we're done and
that the function works?
0:18
We probably load the function
in our terminal, or
0:21
in the browser console,
and just see what happens.
0:24
Even though this tells us
whether our code works
0:27
it doesn't tell us very much about
why it fails when it breaks.
0:30
JavaScript programmers also often add
console.log statements to track variables
0:35
and functions, what the this keyword
refers to, if their math is correct, and
0:40
whether things are happening
in the correct order.
0:45
Consider this gatherNamesOf function
which expects an arrayOfPeople objects
0:48
with names.
0:53
It should return a new array with
just the names of each person.
0:54
Have I written it correctly?
0:58
Maybe you can already see
whether it will work.
0:59
In order to check I might just try running
the code here in my browser console
1:02
to see what happens.
1:06
Well, I see that it doesn't
throw an error right away.
1:08
But I still haven't proven that it works,
I only know that it's valid JavaScript.
1:10
Next, I might try using
the function with a quick example.
1:15
So, in this case, I'll pass an array
of people into the function.
1:19
Then save the output
to the names variable.
1:25
Still, nothing broke,
so that's a good sign.
1:34
But again, I haven't actually proven
that gatherNamesOf does what i want
1:36
because I haven't actually
seen the value of names.
1:41
And if I add a console.log,
1:50
you can see that names is not
what I expected it to be.
1:51
All their names are undefined, and now I
still don't know where the problem is.
1:55
Even after all this generic manual testing
2:01
I have more debugging ahead
of me to fix this function.
2:03
So, this method of checking
code is very tedious.
2:07
And in the end, I'm still unsure of
what went wrong or how to fix it.
2:10
So a number of things makes
this process very low value.
2:14
First, I was only able to see
one specific piece of my code.
2:18
We only have one function in this case,
but imagine if I had a big application
2:22
spanning multiple files and
interacting with one another.
2:26
I would have to repeat this process
across the whole stack to find a problem,
2:30
taking even more of my time and energy.
2:33
I also have to add a lot of code to
my real application just to make
2:36
the test work.
2:40
Now I've littered up my code here
with silly variables and arrays and
2:41
function calls that i don't really need.
2:44
I just put them in here to see
what's happening inside the program.
2:46
That makes my code harder to read and
changes the way my program runs.
2:50
And I also have to remember to
remove everything I wrote just for
2:54
testing before I really
publish my code anywhere.
2:57
For example, var people and
3:01
var names don't really do
anything in my application.
3:03
They're just example test I used
to figure out what's going on.
3:07
And if I forget to remove any of these
statements my application might break and
3:11
cause more headaches.
3:14
Also, even while I'm debugging,
3:16
I have to remember what all my
console.log statements actually mean.
3:18
Usually that means I have to spend extra
time typing little notes to myself from
3:23
inside every console.log.
3:27
Again, we only have one here, but if I
were manually testing a big application
3:29
there might be a lot of these log
statements illustrating the issue.
3:34
Most importantly, these are just
temporary fixes, and they don't increase
3:38
your ultimate confidence in your code
as it continues to grow and change.
3:42
So, what happens if I change
the way gatherNamesOf works later?
3:46
I'll have to go back and
add all of these statements again.
3:51
And maybe have to totally
rethink what I'm testing.
3:53
And I won't know with my changes
affected other parts of my code
3:57
that depend on gather names of
without testing those as well.
4:00
There's a better way.
4:05
We'll still always need this method
of guess and check development, but
4:06
we can accomplish a lot of the same things
more succinctly using automated tests.
4:10
In the next video I'll
show you an example of how
4:16
automated testing improves our
development in all these ways.
4:18
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up