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
Testing is great, but we need to know when to stop!
This video doesn't have any notes.
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
Probably the most difficult
part of testing is knowing
0:00
when you've done enough, testing too
little may result in software with bugs or
0:03
other quality issues.
0:08
However testing too much can
have diminishing returns and
0:10
add too much cost to the project.
0:13
For example, should you test every
unit in isolation using test levels?
0:15
Or is it sufficient to test at
the unit integration level.
0:20
There are no hard and set rules
about how much testing is necessary.
0:23
You may hear very dogmatic opinions
from some about how much to test but
0:28
I believe testing requires good judgement.
0:32
That judgement should be based on
an accurate evaluation of risk.
0:36
Consider what the impact might
be if the software had a bug.
0:40
You've probably heard of some
well known software failures
0:44
resulting in a substantial loss,
failed missions in space,
0:47
massive security breaches, power outages,
failed companies, crashed planes.
0:51
These are just a few examples
of failures in critical systems,
0:56
failures in critical systems
can be catastrophic.
1:00
So the risk is great.
1:03
The more risk there is,
the more testing should be done.
1:05
Such systems should be tested
thoroughly and in every way possible.
1:09
Critical systems are on
one end of the spectrum.
1:13
On the other end could be a simple program
that is only used by yourself to help
1:16
automate a task.
1:21
If this program fails to do its job,
the impact is small.
1:23
In this case,
a sanity test might be sufficient.
1:26
A sanity test simply shows that the
program works under expected conditions.
1:30
It tests the happy path.
1:35
Other times we don't know how
the software we're coding will be used.
1:38
This is often the case in libraries.
1:42
We can make good guesses about how it
might be used by others, but we can never
1:45
be certain especially if the library
is available for public distribution.
1:49
A library for doing Newtonian
physics could be used in a game or
1:55
it could be used to calculate
the trajectory of a spacecraft.
1:59
We need to provide a reasonable amount
of testing and at least inform potential
2:02
consumers of library about
the degree to which it was tested.
2:07
What if we want to use a library
that we didn't code ourselves.
2:11
In that case we need to evaluate
the risk of using such a library.
2:15
We can't assume that the library
was sufficiently tested and
2:20
it may require us to write our own test.
2:23
When using open source code,
good advice is to run
2:26
any tests that are provided with
the code and make sure they pass.
2:30
Review the tests to make sure
that they are sufficient.
2:33
You may want to write your own test.
2:37
If you do write your own test,
you should attempt to add those tests
2:39
back to the open-source project so
that others can benefit from them.
2:42
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