1
00:00:00,360 --> 00:00:04,810
One of the best things about BDD is
that our code is always testable.

2
00:00:04,810 --> 00:00:08,030
It has to be because we
always write our test first.

3
00:00:08,030 --> 00:00:10,760
But if you end up with code before tests,

4
00:00:10,760 --> 00:00:14,690
it can be hard to make a meaningful
unit test for existing functions.

5
00:00:14,690 --> 00:00:17,280
That's because some code is not testable.

6
00:00:17,280 --> 00:00:20,210
The particular nature of
JavaScript means that we have

7
00:00:20,210 --> 00:00:22,990
access to some code and not other.

8
00:00:22,990 --> 00:00:25,370
To demonstrate this,
in the latest project files for

9
00:00:25,370 --> 00:00:29,760
this challenge I have written a pair
functions that handle a computer player.

10
00:00:29,760 --> 00:00:32,620
To make a computer player we have
to give it a programmatic way of

11
00:00:32,620 --> 00:00:34,380
placing ships without us knowing.

12
00:00:34,380 --> 00:00:37,010
And guessing locations during their turn.

13
00:00:37,010 --> 00:00:41,992
So I've named these functions
computerPlaceShip and computerFire.

14
00:00:41,992 --> 00:00:44,741
I want to write tests for
these to make sure they work, but

15
00:00:44,741 --> 00:00:47,480
the problem is that they
produce random results.

16
00:00:47,480 --> 00:00:48,700
And that's the whole point.

17
00:00:48,700 --> 00:00:50,320
If the results weren't random,

18
00:00:50,320 --> 00:00:54,230
then playing against the computer
would be predictable, and no fun.

19
00:00:54,230 --> 00:00:57,766
So, if I write a new suite for
computerFire and

20
00:00:57,766 --> 00:01:02,140
playertest.js, what would I expect
to result from the function?

21
00:01:02,140 --> 00:01:04,490
If the random location
it chooses has a ship,

22
00:01:04,490 --> 00:01:07,230
then I should expect
that ship to be damaged.

23
00:01:07,230 --> 00:01:09,850
But if the random location
does not have a ship

24
00:01:09,850 --> 00:01:12,205
then I should expect
the ship to not be damaged.

25
00:01:13,240 --> 00:01:17,330
I can expect that one of those will
happen, but that's not very meaningful.

26
00:01:17,330 --> 00:01:20,420
It wouldn't tell me much about
what the function is doing to say,

27
00:01:20,420 --> 00:01:27,690
expect (ship.damage).to.have.length{1} or
expect(ship.damage).to.be.empty.

28
00:01:27,690 --> 00:01:31,590
So the way computerFire is
written is not testable.

29
00:01:31,590 --> 00:01:35,290
The only tests we can write for
it are trivial and uninformative.

30
00:01:35,290 --> 00:01:37,430
But we know a lot about testing now.

31
00:01:37,430 --> 00:01:40,830
So by looking at the two
computer functions I've written,

32
00:01:40,830 --> 00:01:44,950
maybe you can find a way to refactor
them so that they're more testable.

33
00:01:44,950 --> 00:01:46,830
Try to rewrite the set of functions so

34
00:01:46,830 --> 00:01:49,470
that we can still generate
random functions.

35
00:01:49,470 --> 00:01:52,580
Now you might need to move
the code generating random numbers

36
00:01:52,580 --> 00:01:56,440
into their own functions in
order to isolate the problem.

37
00:01:56,440 --> 00:01:58,820
And in the next video,
I'll show you my idea for

38
00:01:58,820 --> 00:02:00,240
getting the code to be more testable.