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