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
In order to test a random space picker, we’ll need to refactor our code a little to capture a testable output.
Challenge review
- The way
computerFireis written is not testable; the only tests we can write for it are trivial and uninformative - Refactor the two "computer" functions I’ve written so that they’re more testable
- Try to rewrite the set of functions so that we can still generate random locations
- You might need to move the code generating random numbers into their own functions in order to isolate the problem
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
One of the best things about BDD is
that our code is always testable.
0:00
It has to be because we
always write our test first.
0:04
But if you end up with code before tests,
0:08
it can be hard to make a meaningful
unit test for existing functions.
0:10
That's because some code is not testable.
0:14
The particular nature of
JavaScript means that we have
0:17
access to some code and not other.
0:20
To demonstrate this,
in the latest project files for
0:22
this challenge I have written a pair
functions that handle a computer player.
0:25
To make a computer player we have
to give it a programmatic way of
0:29
placing ships without us knowing.
0:32
And guessing locations during their turn.
0:34
So I've named these functions
computerPlaceShip and computerFire.
0:37
I want to write tests for
these to make sure they work, but
0:41
the problem is that they
produce random results.
0:44
And that's the whole point.
0:47
If the results weren't random,
0:48
then playing against the computer
would be predictable, and no fun.
0:50
So, if I write a new suite for
computerFire and
0:54
playertest.js, what would I expect
to result from the function?
0:57
If the random location
it chooses has a ship,
1:02
then I should expect
that ship to be damaged.
1:04
But if the random location
does not have a ship
1:07
then I should expect
the ship to not be damaged.
1:09
I can expect that one of those will
happen, but that's not very meaningful.
1:13
It wouldn't tell me much about
what the function is doing to say,
1:17
expect (ship.damage).to.have.length{1} or
expect(ship.damage).to.be.empty.
1:20
So the way computerFire is
written is not testable.
1:27
The only tests we can write for
it are trivial and uninformative.
1:31
But we know a lot about testing now.
1:35
So by looking at the two
computer functions I've written,
1:37
maybe you can find a way to refactor
them so that they're more testable.
1:40
Try to rewrite the set of functions so
1:44
that we can still generate
random functions.
1:46
Now you might need to move
the code generating random numbers
1:49
into their own functions in
order to isolate the problem.
1:52
And in the next video,
I'll show you my idea for
1:56
getting the code to be more testable.
1:58
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