Let's start building our Battleship game engine.

In Battleship, there are two grids, one for each player.

Each player secretly places their set of five ships on the grid and

then players take turns guessing where the ships are located.

If you correctly guess that a ship is located at a position on your opponent's

grid, your opponent marks that spot as a hit.

If a ship has been hit at every unit of its length the ship is sunk.

The first player to successfully sink all of their opponent ships is the winner.

[APPLAUSE] >> So

we'll need to write code that handles the current player and winner,

the number of ships, their position, and their status as active or sunk.

I know that sounds like a lot, but

just like our title case function from the end of the previous stage,

we'll use BDD to break all this down into small chunks by writing unit tests.

So let's start with the smallest part of the game, the ships.

Inside the test directory, I'll create a new test file to contain all of the tests

about ship features, I'll call the file ship_test.js.

I like adding the _test into my test file names so

that I can find them more easily later, and it's a bit more obvious

what my error reports are trying to tell me in the test output.

Okay, so let's import expect from Chai first.

So at this point, I can already guess at a few functions we might need.

We'll probably need some kind of function to tell us whether a ship is located

at certain coordinates.

So for example, when a player puts a ship on the board, or when a player tries to

attack, we need to check whether a ship is positioned at the location they're naming.

So let's set up a new suite for this function using describe, and

since the function is just going to check for a ship, I'll name it checkForShip.

Remember, Mocha's representation of a test suite,

the describe function, takes two arguments.

A string describing all the tests inside, and a function to wrap them all together.

So now, let's import the checkForShip function

here at the top of our describe function.

Because all the tests in this suite will need access to it.

Remember this suite will just break at first,

because the function we're referring to here doesn't exist at all.

This is just an outline for now.

So I'm making an educated guess that we'll want to special directory named

game logic, to contain all of our game logic functions, and

that will keep all the ship centered functions in a file of their own.

So what should check for ship actually do?

Well, we'll probably give it a coordinate,

if there's no ship there I think it should probably just return false.

We might change that later if our functions work differently than we expect.

Maybe in the end we need it to return more information than just false.

But for now, that makes sense, so we'll start there.

In Mocha spec looks very similar to a suite.

It takes two arguments, a string describing our desired behavior, and

a function that wraps all of the specs, expectations, and logic up together.

Each spec should be responsible for just one aspect of the function's behavior.

So in order to describe that particular behavior

of checkForShip, I'll name this test spec,

should correctly report no ship at a given coordinate.

That's really informative, it communicates what the spec is designed to prove.

And also, some useful information about the nature of the function.

The function takes a coordinate of some kind.

But I just realize that this isn't enough information.

Because there are two boards in Battleship, yours and your opponents.

So check for ship will also need to accept a player so

that it knows which board is checking for the given coordinates.

So I'll change this to should correctly report no ship at a given

player's coordinate.

It's best to keep a tight feedback loop in BDD, since I've written a lot of

test code already, let's run our test and see what happens.

So in the console, I'll run npm tests.

And I see that I get an error.

It says error cannot find module.

Game logic ship methods.

Well, remember the ship methods file isn't even really it.

So let's go fix that.

So I'll create a new folder named game_logic.

Then, inside this new folder, I'll create the ship_methods.js file.

I'll go ahead and keep my ship test file open to compare against, and

just copy over any code I'll need later.

So I'll start by simply defining the checkForShip

function inside the ship_methods.js file.

Then I'll export it by typing module.exports.checkForShip,

Equals checkforShip.

All right, so that should be enough to get over the import error.

So now if I go over to the console and npm test,

cool, it shows that we're passing our new test.

But we know that's a trick,

because that test doesn't actually contain any expectations yet.

But at least we know where files are connected properly and

that we set up our suite and spec correctly.

Those sanity checks are helpful.

So let's write an expectation for this spec now in the ship test js file.

For this spec to be meaningful, it has to call the function we're testing.

So it's time to make some guesses about how this function actually works.

We need to guess what kind of parameters check for ship will accept,

in order to use it in our spec.

Now we could represent our coordinates in lots of ways, a string of two numbers,

an array, an object and so on.

So I like the idea of arrays since they come with lots of

useful methods built in that we may want to use.

Again, I'm just making educated guesses right now.

When I start writing the game,

the implementation details might challenge our starting assumptions.

So it might be easier to come back and

adapt our tests than it would be to make our functions match our expectations.

So the unit test we're writing just gives me a starting point that

makes sense to me.

Inside the spec, I'll write our expectation, to call checkForShip.

With a player and

an arbitrary location where none of that player's ships are located.

So let's say 9,9.

And since there are no ships there check for ship should return false.

So let's add to.be.false.

Okay, so now if we run npm test in the console,

our test shows that our spec isn't quite ready.

We're trying to pass checkForShip arguments that we haven't defined yet.

The hardest part about BDD is deciding how the function we haven't written yet

might actually work.

We have to make an example of the kind of argument our function might expect, so

that we can use it in our spec correctly.

This is a lot like how we made up an imaginary array of people objects

to test our gather names of function, back in stage one.

The difference is that we don't have the real function in hand yet.

And we're not adding that cruft to our real code files.

These guess work function calls and data structures are just going to live

here in our test spec isolated from all of our production code.

The important thing is to focus on the general behavior of the function we're

testing and not get bogged down in the implementation details yet.

For now, I'll just invent something that will get the test up and running and

kind of make sense.

And if I need to revise it later, then that's okay.

At this point, I'm guessing it makes sense for players to be represented as objects,

since they keep track of different kinds of information.

So right above our expectation, I'll create a player object.

Each player will have a set of ships, so

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

Again,there are lots of ways to represent sets, but

I'll start with an array for convenience.

Since this test only needs us to check one ship, that's all I'll add.

We'll store each ship's location as a property.

So I'll add a locations array to the ship and set it up with just one coordinate.

Let's say 0,0.

At this point we're assuming a lot about the structure of players, ships, and

how we keep track of their location.

It's a lot of guesswork up front.

But even without writing tests,

programmers still do a lot of guesswork as a program.

It's rare that you know exactly how every part of a program works when

you first sit down at your computer.

So, it might feel a little strange to write all of these tests before you start

writing your program.

Just keep in mind that most people also feel awkward when they

first start using outlines for their essays and blog posts.

If you feel overwhelmed by the set up,

just remember that you can always work in a tighter feedback loop.

For example, you could have started this set up work by only writing an object

name player to make that reference error go away in our test output.

Then you would start with another small step and

another until you had something that looked similar to this.

Okay, so now I have a player and it has one ship with one location.

And if I check for a ship at 9,9 checkForShip would return false,

because the ship that player has is located at 0,0.

They don't have any ships yet located at 9,9.

Running the test in the console gives us a new assertion error,

it says expected, undefined, to be false.

Great, we get undefined because our real check for

ship function doesn't return anything yet.

So it's time to start writing our function.

So back inside shipmethods.js, the check for

ship function will accept the parameters player and coordinates.

First, I'll declare two variables inside the function, shipPresent and ship.

Now I know I'm gonna have some kind of conditional block, because I only want to

return false if the player has no ships at the given coordinates.

I know I'll need to loop through all the ships in the ships array and

check each of their coordinates against the one we're giving the function.

So I'll just put this condition inside a loop over all the player ships.

Next I'll save the current ship within the loop to make things easier to read.

Finally, I'll filter the current ship's location array down by comparing each

value to the given coordinates.

So again, this will filter the current ship's location array for

matches against the given coordinate, both the x and y numbers should match.

So this is going to return on an array containing

only the coordinates that are a match.

And if nothing is a match, the array will be empty.

So it will be a coordinate only if there was a match.

The first member of an empty array is undefined,

which will fail conditional and it’s perfect.

It means we only need to save the first element of the filtered array and

use that as a conditional check.

So if the array is empty that means there weren't any matches to our given

coordinates and no ship is present.

Right below, we'll check whether a ship is present at a given

coordinate by saying, if no ship is present, return false.

All right, so now we go over to the console and

run npm test to see if it works.

Great we get all green checks for our tests.