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
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 up