Test Anything Protocol

[00:00:00]
>> So we've seen some problems with just using the core cert package. Although if you have something that's really simple, it's not the worst option. One thing that can help us solve these problems that we had with a cert is both this protocol which is gonna give us some output to look at so that we can see what tests we've run.

[00:00:27]
And it also has ways of determining, that we've run the correct number of assertions so that if we forgot to call a callback somewhere, or if the programme called process that exit zero, that those cases are also gonna be caught by our test suite. So this is a very old protocol, I think I'm not completely sure, but I think It first appeared in the test suite for Perl, which is a old programming language from the 80s.

[00:00:57]
And it's just a very simple way of doing assertions. So I can show you what some of these looks like. So here is some real tap output, the lines begin, the first thing you see is the TAP version. You can put whatever other kind of stuff you wanted in any line.

[00:01:20]
So it's kind of common convention to use a pound because in Perl that's in bash. That's what the comments looks like. And then you see different assertions on their own line. So the main thing that tap specifies is that lines that have a successful assertions will begin with okay?.

[00:01:41]
And then they'll have a sequence number after it, that increments in lines that have failures, we'll begin with a not okay. And they'll have the sequence there. And then, the other very important thing is this, which is called the plan. So this specifies the number of tests that were supposed to be run.

[00:02:01]
So this is a way with libraries that implement the test protocol, how they can say, well, there should be 20 tests running, if there's not 20, if there's more than that, or less than that, probably I'm not calling a callback somewhere. Or I'm calling a callback twice or there's like some way that some branching happened.

[00:02:22]
That's not what I meant. It's not 100% of a way to ensure the flow through your program, but it does catch most of the simple kinds of errors you might make. Okay, so on the chat, Tony asks what was in that file, file.txt, it's just this content. So just three lines.

[00:02:47]
It says one, two, three and there's a trailing newline. So right cat- v was it? I think anyways. Okay, so that's an example of what a successful test run looks like. Let's go ahead, I'm just gonna modify the test suite here to add in a failing test. So I'm gonna say t.ok(false), just to give you an idea for what a failing case looks like.

[00:03:17]
So here we see the line that says not okay. We have the sequence number, so the sequence number always increases. This is just a not yet another way that the tap protocol can kind of just ensure that things are happening generally in the correct order, but it does it automatically.

[00:03:32]
And then it's up to the individual libraries, but a lot of them will provide extra information in these little blocks. Okay, so, I'm just gonna put that back now and we see that it works. Also when you see these things like here, you're gonna get more into NPM scripts in a bit, but we see this line npm error.

[00:03:54]
It's hard to read on the screen, npm knows that our test script failed because the testing library set a nonzero exit code. So set an exit code that was nonzero which you can get out of the command line with this dollar sign question mark?, okay?