You've seen a lot of testing material.

Let's wrap up with some talk about advanced testing features you

might use in the future.

A big part of writing effective test is making sure that your test focus

on one clear behavior.

If your tests have a lot of external dependencies, then it's hard to know

whether they're failing because of the function you're meaning to test or

if actually one of the dependencies is failing.

That makes the test less powerful in debugging because you might have to check

functions other than the ones named in your test spec,

you may not be sure where to start.

For our outlining, we've also seen that it's sometimes helpful to pretend that we

know how certain functions work in order to get started.

We can take this idea even further with mocks and stubs.

Mocks and stubs are two special kind of fake helpers for our test suites.

We've been using fake helpers all along with the fake

objects we set up before each test.

Mocks and stubs are fake functions that fill in the gaps for

our test units dependencies.

Now developers don't always agree about the difference between mocks and stubs.

But I've posted some links in the teacher’s notes that you can read to get

a sense of the distinction.

In this video, I'll show you a stubbed function to get you started

thinking about more complex testing.

We still need a function that will let players take their turn.

That function should ask the current player to guess a location,

fire on that location and then check whether the game is over afterwards.

If it is, then it should return something to stop the game because the game is over.

And if it isn't,

then it should return something that lets the next player take their turn.

Notice again, how I don't really know yet all the details of this function.

I'm just making educated guesses about it to describe its general behavior.

So in game_test.js, inside the game instance function suite,

I'll create a new test suite for that function.

I'll call it takeTurn.

So here at the top of the suite, let's import the takeTurn function that will

eventually be written in the game instance file.

For my first spec, I'll test that takeTurn returns false when the game ends.

So we'll say, it should return false if the game ends.

This function combines several behaviors.

Guessing, firing and checking the game status.

We've already tested fire but

we haven't yet implemented any functions that take input from the player.

That's because we don't know yet about how it will be played.

Will it be in a browser?

Will it require manually typed commands?

Will it use a game controller?

So, we've kept our game engine in the dark about these questions so

that we can use it in a variety of environments.

So using stubs will let us test the logic

that depends on these decisions without having to actually make them yet.

For example, the takeTurn function will probably call a guess function to decide

what happens next.

Since I haven't written these yet, I can introduce a variable called guess,

at the top of my function just like I've been doing for player and ship objects.

So next, I'll create a before each block right above the spec here.

In this block I can set guess to be a pretend function that doesn't do

real game logic.

Now I call these pretend functions because they

just return the values I would expect the real working functions to produce.

Guess will gather a location

from the current player that they want to fire a shot on.

This could be from a click in the browser or

typed in the command line or some other method.

Maybe it will even be spoken into a microphone, who knows?

So no matter how players interact with guess,

it will somehow need to return a valid coordinate.

So that means I need to set guess to be a function that returns a valid coordinate.

So inside the before each block, we'll say, guess = function.

And inside the function, will return the coordinate [0, 0].

So now no matter how I write guess in the future,

this test ensures that takeTurn does what I expect with the return value.

Finally, takeTurn needs to know which player is taking their turn.

So I'll initialize a player variable at the top.

Then pass in a player object in my beforeEach block.

I'll set a ships array as a property on the object.

Then I’ll add a locations and an empty damage array to ships.

So now, inside the spec if I call takeTurn with a player and

the player guesses the last ship location of their opponent, the game is over.

So I'll call takeTurn and pass player and

guess as arguments and save it to a variable named actual.

And again if the player guesses the last ship location of their opponent,

the game is over.

So in this case, takeTurn should return false.

So we'll say expect actual to be false.

So now, even though I have no working guess function,

I've set up the spec to pretend that those parts of my code already work.

That's the only important information this test needs.

If I bring up my console and run my test.

My test fails, it says, takeTurn is not a function.

So now I’ll jump over to game_instance.js and write the takeTurn function here.

So right below checkGameStatus, we'll say, function takeTurn.

The takeTurn function will take a guess function call back and

it will use this to save a guess.

So we'll save a guessFunction in a variable named coordinates.

The function will also take an opposing player call back to fire on the opposing

player at those coordinates.

So we'll also pass opposingPlayer.

Then in the function will call fire and

will pass opposingPlayer and coordinates as arguments.

So now up top will need to import the fire function from ship_methods.js.

So next to check whether the game is over,

we'll declare a gameOver variable which calls checkGameStatus.

And in the end the function returns the resulting status of gameOver so

that we know whether to let the opposing player take their turn.

So we'll say, return gameOver.

And finally we'll export the takeTurn

function here at the bottom of the file by typing

module.exports.takeTurn = takeTurn.

All right, so let's save our file, bring up the console, and run our tests.

So great, even though guess has not been written, my test passes.

The test spec used my stub version of the guess function instead.

So it got all the values it needed just for testing my logic.

So now I know that the logical structure of takeTurn is correct.

So I can move on to writing something else.

Another benefit of this stubbing is that even while I'm working on

the checkGameStatus and guess functions, tinkering with them to do this or

that my take turnTest will keep passing.

takeTurn gets the value, I ultimately expect those functions to return

no matter how those functions actually work.

There are whole libraries dedicated to making stubs easy to write,

like Signon.JS.

Signon lets you set up pretend servers, HTTP requests, databases, and more.

So if you wanna learn more about mocks and

stubs, you can check out Signon's home page to see many more examples.