Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.

Preview

Start a free Basic trial
to watch this video

Sign up for Treehouse

Challenge: Writing Testable Code

2:00 with Guil Hernandez and Joseph Fraley

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