A nice feature of Mocha is that we can outline tests that need to be written before we’re ready to write them. So when you have an idea for a test, but you aren’t yet sure what it will look like, you can still communicate your idea to other developers and get started.
- To mark a test as “pending”, do not add a function as a second argument
- You can also mark tests as "pending" by typing an
xin front of the pending block, like
- Adding an
xin front of the
describe()block marks all of the specs inside as "pending"
In some ways being a programmer is more like being a writer 0:00 than being an engineer. 0:03 It requires a lot of creativity and you can get stuck a lot waiting for 0:05 inspiration to strike. 0:09 A nice feature of Mocha is that we can outline tests 0:11 that need to be written still before we're ready to write them. 0:14 So when you have an idea for a test but you don't have time to figure it out, or 0:17 you aren't yet sure what it will look like, 0:22 you can still communicate your idea to other people and get started. 0:24 Let me show you an example. 0:28 In order to play a game, it would be nice to have a function 0:30 that checks whether the game is over after each turn. 0:33 That way, every time I make a guess, the game engine will check and 0:36 see whether I've struck the last ship in one or 0:39 whether the next player should start their turn. 0:42 I know I need that, but I'm not ready to think about how it works yet, 0:44 not even to write the tests. 0:48 So I can write a pending test spec to keep track of those tests I have to 0:50 write later. 0:53 Inside the test folder I'll create a new test suite file called gametest.js 0:54 since this suite will focus on functions pertaining to the flow of the game. 1:00 So first I'll import chai at the top of the new file so 1:08 that we can use it here as an expectation. 1:12 And now I'll set up the fundamental describe block for the suite. 1:23 And as the first argument I'll write, GAME INSTANCE FUNCTIONS in all caps. 1:36 This is only here to make the output nicer for me. 1:42 I'll call the function I'm testing here, checkGameStatus. 1:47 So I'll create a new test suite for it. 1:50 Now, a test spec that I know I should write for 2:08 this function confirms that it should tell me when the game is over. 2:11 So I'll create a new spec that says, it should tell me when the game is over. 2:15 This is a pending test, so in order to mark this test as pending, 2:26 I do not add a function as the second argument. 2:30 The it block is only written with the first argument describing the test. 2:34 And it doesn't contain any expectations yet. 2:39 So now if I go over to the console and run npm test, 2:42 It showed me that I now have 15 tests passing and one pending. 2:50 Notice the pending test is in a different color so they're easier to see. 2:56 In my console the test is light blue. 3:01 This is really useful as a reminder to myself and 3:08 others that some tests need to be written still. 3:10 It's like having an outline for my outline. 3:13 It communicates some information for getting started. 3:15 I can also mark tests as pending by typing an x in front of the pending block. 3:22 Like, xdescribe, 3:27 or, xit. 3:33 For example, if I add a regular test spec to my current suite, 3:44 even though I've added a function as a second argument, 3:50 I can add x in front of the describe block, and 3:55 all of the specs inside will be marked as pending. 4:00 I prefer leaving out a callback to using xdescribe, 4:16 because I don't have to delete anything later. 4:20 I just have to continue writing the test spec as I normally would. 4:23 You might see this done both ways, so 4:27 feel free to use whichever method you like better. 4:29
You need to sign up for Treehouse in order to download course files.Sign up