Testing asynchronous functions can be a unique challenge.

Our battleship game doesn't have any asynchronous elements but

we might want it to.

For example, If it were played across an Internet connection on two computers,

one player would have to wait for the other's turn.

If we wanted to save our game somewhere and

start again later we'd need to connect to a database that stored our game state.

Those processes would probably be synchronous for efficiency.

Mocha allows us to say that a test back or test suite is asynchronous.

So passing an argument to the internal function of a describe or it block,

we'll tell Mocha to wait on running our expectations until we specifically say so.

Let me show you how it works.

I'll create the function inside the main GAME INSTANCE FUNCTIONS suite right below

the takeTurn suite.

Now, in this function we'd normally have to write some code to communicate with

a remote database.

But instead, I'll simulate that idea with a setTimeout function.

So setTimeout will perform whatever function we describe after a specified

number of milliseconds.

If our game really communicated with a database the seTimeout

function would be replaced with something that sent a request to our database.

So I'll set the function to run after one second has passed, or, 1000 milliseconds.

So after one second the database function would finish and perform some callback,

like telling the player that the game was saved successfully.

So let's pass callback as a parameter of saveSame.

Then we'll call callback inside setTimeout.

All right, so now we can create the test suite for saveGame.

So right below the saveGame function, as always,

we'll create a new test suite by typing, describe.

And we're going to name this one, saveGame.

And then I'll open my first spec for this function inside the suite.

So we'll say, it('should update save status').

And now I have a space to write some expectations

about how saveGame should work.

So to test synchronous functions like the ones we've written

before now in the course, I would run the function inside of my spec and

then write an expectation about something that changed as a result.

So to use that strategy in this case, I might try running saveGame with a callback

and writing an expectation at the end of the callback to capture the new results.

So let's do that, at the top of the spec I'll save the string, game not saved,

in a new variable named status.

Then I want saveGame to change the status to, game saved, when it finishes.

Again, in reality, that would mean the database responded successfully.

But in this example it's just going to wait one second and

then use my callback function to update the status favorable.

So inside saveSame we'll say, status = game saved.

Finally, I'll try expecting the status to equal game

saved after I've called saveGame.

So right below saveGame, we'll say expect(status).to.equal('game saved').

So now if I bring up the console and run my tests,

We can see that the test reveals a failure.

The expectation runs before the saveGame function is called because saveGame is

waiting 1000 milliseconds to fire the callback that updates status.

So that means status will still equal game not saved

until an entire second has passed, which we can see it's

much longer than our test suite takes to reach the expect(status) line.

So to fix this problem, I need to move my expectation inside the saveGame callback.

So that it only happens after saveGame has finished updating status.

So now if I go back to the console and run my test at this point

It looks like the tests pass.

But that's kind of tricky.

Mocha is just running through the test function before saveGame finishes.

And then reports that the test spec passes because they didn't see any

expectations written.

So for example, even if I write a definitely failing expectation into

the saveGame callback, like expect(true).to.be.false;.

Mocha still passes our tests.

So we need a way to tell Mocha to wait until saveGame has finished running

in order to check our expectations.

To do that, I can pass a special argument to our test specs callback function.

By convention we call the argument done so that we know the argument is signaling

Mocha that our test code is ready to be run after some a synchronous operation.

We normally just use the test spec callback to contain our test code and

expectations, but by passing it an argument

we signal to Mocha that we want this test to run asynchronously.

So now I'll delete this example expectation.

Then run, npm test.

And now we see that the test gives me a new error that says,

saveGame should update save status:.

Then the error says, timeout of 2000ms exceeded.

Ensure the done() callback is being called in this test.

So it looks like the error is asking for me to call the done() callback.

Passing the done argument to our test spec tells Mocha that it's supposed to wait for

instructions before checking our expectations.

So we passed the done argument but

we haven't used it to tell Mocha when our code is ready to be tested.

So, in the saveGame callback,

I'll add done() after the changes I expect to occur.

And now Mocha will wait for

done to fire before checking the expectations.

So when we run the tests now.

Great, everything works.

And notice that there's a short pause while the tests are running.

That's Mocha waiting one second for

the setTimeout function to run before checking the expectations.

Writing asynchronous code and testing it correctly is a big topic.

Usually you'll write mocks and stubs for your database or AJAX calls because

those are big external systems that you don't wanna mix into your test unit.

Just know that Mocha gives you a way to deal with these problems.

So, you might need to research the best way to capture the test results you want

when you encounter them.

So congratulations getting started with JavaScript unit testing.

Good unit testing takes practice.

And there's a lot more you can learn and do to improve the quality of your test and

also to make writing tests easier.

If you've never written any tests this testing first approach is different from

what you're used to.

And at first it can feel like a lot more work.

As you get better writing unit tests really will improve your code.

It will also save you lots of time fixing bugs and

explaining things to other developers.

So dig into Mocha and chai and

let us know in the community when you find useful tips and tricks.

Good luck and happy testing.