Welcome, welcome everyone to today's <a href="/tags/nodejs">Node.js</a> Test Run <a href="/tags/workshop">workshop</a>. Let me introduce myself very briefly. So, my name is Marco Ippolito. I work at Neo4j as a senior <a href="/tags/developer-experience">developer experience</a>. I'm a <a href="/tags/nodejs">Node.js</a> core contributor. I'm a releaser, so I'm releasing new versions of <a href="/tags/nodejs">Node.js</a>. I also work on the <a href="/tags/automated-security">security</a> team of <a href="/tags/nodejs">Node.js</a> and take care of HTTP stack, but I also help on other open source projects like Express and <a href="/tags/fastify">Fastify</a>. So, if you want to talk after this <a href="/tags/workshop">workshop</a> about anything open source and <a href="/tags/nodejs">Node.js</a> related, feel free to write me in on social media.So, let's get started. So, what is a test runner? I want to go into a little bit of theory before we start writing <a href="/tags/code">code</a> so that we are on the same page. So, the test runner is basically that part of an application that runs, that picks and runs the <a href="/tags/javascript">JavaScript</a> <a href="/tags/code">code</a> and executes it. So, the test runner is the <a href="/tags/cli">CLI</a> tool that you use to run tests. The test runner itself doesn't know anything about what's inside the <a href="/tags/javascript">JavaScript</a> files. It only selects and executes them. Usually, a test runner comes in with the test <a href="/tags/frameworks">framework</a>, and that's the <a href="/tags/javascript">JavaScript</a> library that you use inside your <a href="/tags/javascript">JavaScript</a> file, your <a href="/tags/javascript">JavaScript</a> test file to execute tests in a different order. And that's what basically, that's what the content of the test. But the test runner takes care of the execution.So, the most common features of the test runner are test discovery, and in this case, running everything that is inside the test folder by default, or test organization, to make sure that all the tests are categorized and grouped depending on the labels that you add. For example, you want to filter some tests, you want to execute <a href="/tags/typescript-libraries">TypeScript</a> tests, but you don't want to execute some others. You can do that. It takes care of reporting. You can, like, the output of a test is very important. You can choose different outputs, machine readable, human readable, depending on your needs, and also integration support. Well, you want to be able to run your test suite inside a continuous integration system, like <a href="/tags/github-actions">GitHub Actions</a>, Jenkins, whatever, so the output of the test runner must be easily consumable and the result should be zero or one.

So, the interesting thing is that every other programming language has built-in test runner and <a href="/tags/testing">testing</a> <a href="/tags/frameworks">frameworks</a>, but not <a href="/tags/javascript">JavaScript</a>. So, that's because <a href="/tags/javascript">JavaScript</a> traditionally tries to keep its core very small and all the <a href="/tags/javascript">JavaScript</a> runtimes, like <a href="/tags/nodejs">Node.js</a>, historically agreed to that principle to keep the core very small, so it delegated everything to <a href="/tags/npm">npm</a> packages. But in other languages, we have, for example, in Python, we have PyTest, in Java we have Junit,.NET, we have NUnit, we also have XUnit, but every language has a different test runner, Go has GoTest for example, but there are also libraries, for example, in <a href="/tags/javascript">JavaScript</a>, there is a huge amount of <a href="/tags/testing">testing</a> libraries. There is Jest, VTest, there are at least 15 that I can count. So, as we said, the test runner is the tool that executes the test and exports the result. The test <a href="/tags/frameworks">framework</a> is the <a href="/tags/javascript">JavaScript</a> <a href="/tags/code">code</a> that provides the structure and the guidance from <a href="/tags/testing">testing</a> tests, like assertion, test cases, test suite, but <a href="/tags/testing">testing</a> <a href="/tags/frameworks">framework</a> is not capable of running tests by itself. We also have a third component, which is the assertion library, that can be considered part of the <a href="/tags/testing">testing</a> <a href="/tags/frameworks">framework</a>. So, that's the library that takes care of making sure that it runs the assertion, makes sure that the qualities are respected, etc. Most of the tools do the same thing, like Jest provides test runner, tests <a href="/tags/frameworks">framework</a>, provides everything. Mocha provides the test runner and the <a href="/tags/testing">testing</a> <a href="/tags/frameworks">framework</a>. <a href="/tags/cypress">Cypress</a>, for example, is built on top of Mocha and it only enriches the <a href="/tags/testing">testing</a> <a href="/tags/frameworks">framework</a>, but the test runner is Mocha. So, it really depends. There are so many <a href="/tags/javascript">JavaScript</a> libraries for doing <a href="/tags/testing">testing</a> and that's one of the main reasons that why <a href="/tags/nodejs">Node.js</a> decided to build the whole test runner.So, the first reason, and probably the most important one, is because it improves a lot the <a href="/tags/developer-experience">developer experience</a>. Whenever you get started on a <a href="/tags/nodejs">Node.js</a> project, you want to be able to do everything that you have to do without installing external <a href="/tags/npm">npm</a> packages. So, it simplifies setup and also simplifies life for new developers who try to use <a href="/tags/nodejs">Node.js</a>. They have everything, batteries included, so they can just run tests. Standardization, this is one of the long-term goals. So, with time we would like to have the same test syntax for the whole <a href="/tags/nodejs">Node.js</a> system, and also because libraries, authors, can build on top of the test runner without having to reinvent the wheel every time. <a href="/tags/performance">Performance</a> because the <a href="/tags/nodejs">Node.js</a> test runner is extremely fast. It's much, much faster than any other <a href="/tags/npm">npm</a> library. And in terms of features, it's not as bloated or doesn't have as many features as other <a href="/tags/npm">npm</a> libraries like Jest. We will see that the <a href="/tags/nodejs">Node.js</a> test runner is quite new. It has been stable for one year. So, it will take some time to get the <a href="/tags/community">community</a> to build stuff on top, but eventually I assume it will become the go-to for <a href="/tags/testing">testing</a> in <a href="/tags/nodejs">Node.js</a>. Okay, so in this <a href="/tags/workshop">workshop</a>, we will see some of the features of the test runner and we will do some exercises. Whenever you see the light bulb icon, it means that there are <a href="/tags/tips">hints</a> and we will have 11 exercises that you have to manually do. This <a href="/tags/workshop">workshop</a> is very interesting because it uses some cool <a href="/tags/nodejs">Node.js</a> features that you probably don't know about. But we will talk about that at the end of this <a href="/tags/workshop">workshop</a>.For this setup, as a requirement, we will need Node-LTS, but I suggest you to use Node21. Whatever Node 20, like the latest version of 21.7.3. If you use NVM, that's gonna be much better. And then we will clone from this URL from GitHub, Neo4j-node-test-runner-workshop, and then run npmci. Let's wait a couple of minutes so everyone clones the Git repository and we will get to the next step. So I will wait a couple of minutes. This is the GitHub, you can download it from here. If you need to install, use NVM. If you have NVM, just run npminstall21 and npmuse21. The reason is that we are using some of the latest <a href="/tags/nodejs">Node.js</a> features. And I personally tested on 21, but I'm quite sure it also works on 20. But let's not risk it, okay? How does it work? In the first example, we will run, this is 00. It's a very trivial test example. This is just to get you comfortable with the <a href="/tags/workshop">workshop</a>. So we have three tests. One for, we have three functions, sum, product, and average. And we want to open a new <a href="/tags/cli">terminal</a>. Let me share. So we open a new <a href="/tags/cli">terminal</a>. We should be in the source, 800. Okay, and then we run npmgp. Okay, and that's it. So I hope that it works for everyone. This was just a test to make sure that everything was up and running. So in this example, we see that when we run node dash dash test, Node will automatically execute all the test.js files inside the test folder. And so we don't need to configure anything specific. So it will assume that your tests are by default in the test folder. Okay, so if everything works great, we can go to the first real exercises. Filtering. So filtering is something very important. Because we don't want to run all the tests all the time. So imagine you are developing a new feature and you have very large <a href="/tags/code">code</a> base, you want to be able to run only a bunch of tests that are relevant to the feature. So that you don't have to wait a lot of time. You can run fewer tests. There are many ways in which you can filter. You can filter by test name, you can filter by folder. So the key point of this exercise is that you can selectively run tests by name, tags, or custom <a href="/tags/patterns">patterns</a>. And this is something quite important. So for this exercise, imagine that you start with the project that's legacy and has the test in another folder. That's not slash test. So you want to be able to run the test runner specifying in another folder that's called test folder custom.

And also, the file extension is not.test.js, but.spec.js. So you want to be able to tell test runner that you want to run in another folder, and you want to run another extension. If you run it by default, it doesn't work. So let's go to exercise number one. Okay, if we run and we try to run <a href="/tags/npm">npm</a> test. We're not running anything, okay. Zero test executed. So we want to be able to run tests by name. Okay, zero test executed. So we want to be able to execute those tests. So the <a href="/tags/nodejs">Node.js</a> test runner provides a flag called dash dash test name pattern. So you can use this test for enable filtering of tests based on their names. And you can also specify the folder in which you want to run those tests. So, let's use this. Let's use this flag to run the tests in the specific folder. So this is test. We have test folder custom here and we want to be able to run this one, this test. So I will give you a couple of minutes and then we will do it together so you can start to experiment. This is also very easy and difficulty will increase with more exercises. So you can use this flag here to run the specific folder. Okay, so let's wait two minutes and then we will see the result. Okay, I think we can see the solution together. So, as I said, you can run, you can run in the specific folder, just like here, we can run test folder custom spec and we can also filter by the name of the test itself. Like we want to run only product, we can pass product and the path and it just work. This is very, very useful. So imagine, for example, that you have a bunch of tests that are specific to a feature and they are called like product something. So you can run all the product test without having to run the whole test suite. So any questions on this one or we can move to the other exercise? What kind of wildcards are available? So you can specify by path wildcard and extension wildcard. Like you can basically, I think it's quite flexible. You can also filter by test name. For example, with the act. I haven't played too much. I don't think there are, there are like, it's not a full template engine, like you cannot add variables into it. I think it will just match the, like match the name of the test by some path. Well, we can have a look at the <a href="/tags/documentation">documentation</a> if it says more on it, but I doubt. But always PR is welcome. If something is lacking on <a href="/tags/documentation">documentation</a>. Did you know, did you check the Neo4j website? Should we see the output of the test even if we're on? No. <a href="/tags/npm">NPM</a> solution. Yeah, as you can see, only this one has been run. The other two has been ignored. So yeah, you see them in gray, but they have been skipped. You see that they are skipped. No, wait. That's the runner. That's path name. That's name pattern. Oh yeah, so you actually have some templating, like you can, with numbers, and you can use regex. So that's quite powerful. No. On your <a href="/tags/cli">console</a>, they're not great. Check the <a href="/tags/npm">NPM</a> run solution. The solution... The solution here, and you can run it. And as you can see here, and those two are great. What version of Node are you using for Curiosity? No. Okay, let's see. <a href="/tags/npm">NPM</a>, you use 20. Let's see if it's... For me, it runs on Node 20. Node 20. So I guess it's on your machine. Did you run <a href="/tags/npm">NPM</a> <a href="/tags/ci-cd">CI</a>? Yeah, <a href="/tags/npm">NPM</a> <a href="/tags/ci-cd">CI</a>. It might be you're missing something, but that's weird. Okay. Okay, okay. So it was a typo, probably, on your side. Anyways, it's good that we encountered issues on the first one, so that we can fix them and do the test later. Okay. So I will move to exercise number two.

So this is the solution. Hope you can also check it inside the package.json. Okay, number two is assertions. Node, the essential library of <a href="/tags/nodejs">Node.js</a> is actually older than the test runner. It has been in Node since Node 12, I think. So we have two functions. One is sum and one is sum.sync. And we will make sure that the result that are by these two functions is correct. So we will validate that our <a href="/tags/code">code</a> behaves as expected.So in exercise number two, as usual, go into the folder. Let's write test with the proper assertion, and we will follow the guide. There are a few comments in the test file, and you need to follow them. Make sure that you implement your assertions correctly. So let's have a look in which what I'm talking about. So that's cda02. Sessions, you're going to sessions. We're going to test, and we see the index. So we need to implement all these assertions inside the, like we want to make sure that the type of, is a number. We want to show that an empty array is a valid input. We want to make sure that the sum of the array, of an empty array is zero. We want to make sure of all of these, these are our requirements and we want to test them. These are all the assertion that the assertion, <a href="/tags/nodejs">Node.js</a> assertion library gives us. One thing that really, really lacks in the <a href="/tags/nodejs">Node.js</a>, in the assertion library, and I really want it is the snapshot. Assertions, are you all familiar with snapshot <a href="/tags/testing">testing</a>? It's when you check that the output of something is equal to what you expected. And to be honest, we shipped it in Node 18, but we had to remove it because it was not good enough for production. And I really miss it. So to like, we need to run and be able to run <a href="/tags/npm">npm</a> run verify, and to verify that you did it correctly, you need to run <a href="/tags/npm">npm</a> run verify. And as you can see, it will throw a bunch of errors, saying, hey, you need to call assertion okay, you need to call assertion this, assertion that, to make sure that you have called all these assertion here. Okay. So, this is haid. The session syntax is similar to the example. You just need to customize it. And on top you have all the possible session. So I'll give you five minutes and then we will check together the solution. Meanwhile, if you have any questions or any problems, I'm here to assist. The good thing about this <a href="/tags/workshop">workshop</a> is that we are able to validate if you have used all the assertions that you're meant to use. So if you run <a href="/tags/npm">npm</a> run verify, it will validate the test. So there is a test that tests the test. That was quite cool to implement. I will make sure to run the <a href="/tags/ci-cd">CI</a> of this test run on the windows to see if everything works. With GitHub Action, it's very easy. Also, just to mention, as you saw this <a href="/tags/workshop">workshop</a> is open source. And it's in GitHub, so if you want to suggest it to someone else, you want to reuse it, you want to improve it, you want to do whatever, you can just go ahead and open the R, fork it, see how things are implemented. It's fully open. Also the slides are in the <a href="/tags/workshop">workshop</a> itself. So if you are not sure about something, you can always go back and rewatch the slides if they're part of the <a href="/tags/workshop">workshop</a>. Okay, let's have a look at the solution. So, well, it's actually pretty straightforward. We will have to check that the result is equal to something used, deep-street equal. You want to make sure that the result of an inequality is true. You can use assert, okay. You want to check that something does not throw. For example, in this case, if we pass an empty result, zero. As before, if you pass empty array, you want to make sure that the result is zero, and you want to make sure that if you throw something that's not an array, it throws. So if we copy paste this one in the solution, and we tried to run <a href="/tags/npm">NPM</a> test, <a href="/tags/npm">NPM</a> run verified, we see that we did not complete a sum async. So as the two are fairly similar, you can just await inside the deep-street equal. The only difference is that you will have to use does not reject instead of does not throw, and assert rejects instead of assert throws. Always remember the await here, otherwise it doesn't work. If you don't await the assertion, it will not work. There are also two assertion, but that are not covered by this exercise. This assertion match and assertion does not match. So if we copy paste this too, <a href="/tags/npm">NPM</a> run verified, it should pass. The cool thing is that if I remove an assertion here, this one is repeated twice, this one is repeated. So if I remove this one, for example, and run test, it works with, it should be throwing an error. Wait. An error built in this. Okay. Okay. So we implemented all the assertion from the assertion libraries. Let's see, number two.

It's pretty straightforward. It's very similar to any other <a href="/tags/testing">testing</a> library that you have used. And so, are there any questions on this topic? I think it's a pretty straightforward. There is nothing particularly peculiar about the assertion library. So I think we can move to the next one. If you want to have a look at the <a href="/tags/documentation">documentation</a>, you'll find it here, in the <a href="/tags/documentation">docs</a>, about assert. There are some cool features that we haven't covered.So, number three, we have parallel <a href="/tags/testing">testing</a>. If you have a very large test suite, you can run your tests in parallel and reduce the overall computation time. So if you run this command here, OS available parallelism, you can check, how many, you can make sure how many CPU core you can use. You will always have one free. So it will take the amount that you have, minus one. By default, this is already enabled. So whenever you use the <a href="/tags/nodejs">Node.js</a> test runner, you will use the maximum <a href="/tags/concurrent-rendering">concurrent</a>, maximum parallelism minus one. You can also increase the test <a href="/tags/concurrent-rendering">concurrency</a> manually. So we will do a little exercise here and we will try to start from one and move to the default one to see how fast that it gets with available parallelism.It's important to note that if you are running this on server, you might want to tweak with configuration. So if, also it really depends a lot on what you're <a href="/tags/testing">testing</a>. If you have something, every computational, you really, really want to use the parallel execution. So imagine that we have a function that takes a long time to execute. So we have a heavy computation sum and heavy computation multiply. This function thing, take a long time to execute. So as usual, we go into exercise number three. And we run Node test with <a href="/tags/concurrent-rendering">concurrency</a> one. So it's taking a long time. Okay, because it's using just one core of my CPU to do all the tests. Okay, takes very long time. Okay, it took like 24 seconds, something like that, it took a lot of time. So we can improve it by a lot. So let's try with, by checking again, our available parallelism. So it's 10, so we can run the same command. The default <a href="/tags/concurrent-rendering">concurrency</a> is the maximum minus one. So like literally this, I implemented something on source <a href="/tags/code">code</a>. So I remember seeing how it's implemented. So it literally does the same thing as I'm doing right now. So it takes OS available parallelism minus one. That's the default. And so if we try to run the same exercise and we make it to 10, we will see that it is much, much faster. Okay, it literally took six seconds against the 24 of four. So it's extremely faster. This one, I suggest you to do the same thing. Let's see another interesting topic that I want to discuss about. It's like when you have very large test suite, you can use sharding, and this feature is not well known. People know about it. But you can shard the test suite into pieces. Let's see if I can find some more. Okay, so this is literally, all right, let's see if I, oh wait, probably it's in <a href="/tags/cli">CLI</a>. Yeah, not <a href="/tags/documentation">documentation</a>, to be honest, it's not the best, but I want to show you anyway. Shard. Okay, so we have this flag called test-shard. Not many people are aware of it, but you can run, you can split your test suite into pieces. Like you want to run half of the test on one machine and another half of the test on another machine, you can do it. Imagine that on one machine, you run node test-shard one half, and on the second machine, you run node test-shard second, two out of two. So this is very useful for extremely, extremely large test suites. And you can split it and run it on different machines. So I don't know why this one is not talked a lot, but it's something that other, like it's not very common to see, and it's very useful if you know about it. So I will probably add it to the <a href="/tags/workshop">workshop</a>. So, okay, that was it. Were you all able to run, to run this exercise? Are there any issues or questions that you want to ask? If you run, like, if your server is running a lot of other, like if you run a test on a server that's already being stressed, I do not suggest you to use all the cores because some stuff freezes, or like not work properly, so only use maximum <a href="/tags/concurrent-rendering">concurrency</a>, not like on your machine and probably not in a protection server or an environment that's, that where <a href="/tags/performance">performance</a> is very important. All the tests contained inside a single file are not run concurrently, right? If you, like by default, if you run a test, you will see that they are run with maximum. It took six seconds. So how does it work really in reality? Let's see test, we have some, so when we use the test syntax, it will, test is a synchronous function. It returns a promise. So if you use the test syntax, you can do a wait and all of this are run <a href="/tags/concurrent-rendering">concurrent</a>. If you use the hitDescribe syntax, the hitDescribe syntax is, they will be executed one by one. They will not be executed <a href="/tags/concurrent-rendering">concurrent</a>. So the test inside the single, inside the single test file, they keep the order obviously, but the four test, the four test files are executed concurrently. The <a href="/tags/concurrent-rendering">concurrency</a> is in a test file execution, not inside the <a href="/tags/javascript">JavaScript</a> by itself. But if you use the syntax, you can do a synchronous <a href="/tags/testing">testing</a>.

But if you use the syntax, you can do a synchronous <a href="/tags/testing">testing</a>. They will be as promises. If you use the hitDescribe syntax, they will keep the order. If I don't have time to wait here, this is like calling a promise without awaiting it. So I hope that answers your question.Okay, let's move to exercise number four. We have context. So context is something that's very important. Because when we create tests, we also want to set up some stuff. We want to be able to, I don't know, like <a href="/tags/database">database</a> connection. We want to create something and we want to clean up at the end. So the context is essential to manage the test lab cycle. It provides a bunch of hooks like before, before each, after each. I think those are self-explanatory. Before it's at the end of the test, before each, before every single test. After is at the end of the test suite. And after each, at the end of every single test. It allows you to skip some tests. It allows you to mark some tests as to-do. When you mark tests as to-do, even if they fail, the result will not impact the overall result. If you run some, if you set something as a skip, it will just not execute at all. The context, we can have a hierarchical structure. So we can create sub-tests. We can create sub-tests into sub-tests. So hierarchical test structures. And we can also add hooks inside the hierarchical test structure. We will see in this.Okay. So in this exercise, we will focus on child sub-testing. We have a file called index test.js. You will find multiple tests for sum and average. We will have to group them together using the describe function. So let's go. I34. Okay. We see here, we need to run and run verify. Okay, you need to do the describe to create the test suite for the average sum and average. We have a bunch of tests that are written individually. We want to group them and to create a big test suite and then test cases for that, for sum and one for average. So we want to group them. Remember the test is synchronous. So you need to await it. But if you use describe, you don't need to. So this is something weird, but like if you use test inside another test, you need to await it. But if you use test inside describe, you don't need to await it. This is because describe wraps, it's called the test suite. It's a test with object, and it wraps all this test in a specific way. So it will return just one promise instead of like eight. And so it will execute all of those one by one. The weird part is that we created now from node 21 point, one of the latest node 21. There is a new keyword for which we... that replace, it's suite and describe are the same thing. They are the same. They do the same thing. They are just another name because describe and it is the BDD syntax, but we didn't have like the same alias for describe when using test. So suite and describe are the same thing and test and eat are the same thing. They are equal, they behave the same way. Just as a reminder. So, okay, let's do this exercise together. Let's group them and give you five minutes and then we will go through it together and we will see the solution.

Okay, yeah, we have suite. Let's see. Okay, to be released in node 22. So it has not been released yet. That's why you don't have it. But it's a short name for describe. They do the same thing. So solution is that you can use the describe to wrap every test that is related to some. This is useful for filtering because obviously you can run everything, you can group all the tests for a specific topic inside one test suite and then run them one by one. In this case, if you use describe, you don't need to await, but if you use test inside the test, you need to await. This is very important. That's something that it's a bit tricky. Same thing for average. You create just one describe function. Then you write all the tests inside of it. As before I said, you don't need to await it. If you don't use the describe, you need to await them. So describe, it's only for, it's to run tests in order. From node 22. From next week, you'll be able to call it suite. It's an arias for describe and do the same thing, but it's a better name in my opinion. Yeah. That's cool. Any question on this topic? This is one of the things that users find it hard, I think it's a bit tricky to understand, not to understand grouping by itself, but to understand how some <a href="/tags/testing">testing</a> will work in TestRunner because it's very different from other <a href="/tags/testing">testing</a> <a href="/tags/frameworks">frameworks</a>. So I want to make sure that you all get it, especially with synchronous and asynchronous. All right. No questions, I will move to the next one.So we have hooks, as I mentioned before. Context is something very important. So we want to be able to run the hooks to set up the context, to set up the environment, <a href="/tags/database">database</a> connection, etc. Like everything that requires something external, it needs to be set up by a hook. They help a lot with making our test suite much, much more readable, because imagine like, changing a global variable in every test it's a mess. If you forget to reset something, that also becomes very messy. So hooks are a very important feature. Let's see the exercise. So I imagine a test suite that has multiple tests that interact with <a href="/tags/database">database</a>. So you want to, like, you don't want to handle <a href="/tags/database">database</a> connection all the time for every test. It's very repetitive. You want to be able to use hooks to set up the connection and drop it when you're done. Yeah, so we want to use the proper hook life cycle. So I don't like that b4-inch does only count in the first layer inside its body, but nested the scrap before all will no longer let the parent before all be executed for each. So, I will be completely honest. I wanted to change this behavior, so that hooks run in a more specific order, but I did it and I broke node 21.7.0. I broke it. I broke a lot of stuff by changing the order of the hooks with my commit. So we had to release a patch after two days to restore the previous order. So yeah, I guess I broke node for a couple of days and did not test runner. Yeah, but it's a bit tricky. Yes, I do agree. It's a bit tricky and could be improved a lot, but for now it's what it is. So, okay, let's get started as usual. Let's go to A, C, D, A, to D5. Oops. Okay, so this is the file. We have <a href="/tags/database">database</a> connection. We have a lot bunch of stuff here that interacts with the connection. So we want to change this and make sure to use hooks to set up the correct object lifecycle. Like we want to start the lifecycle for the user and <a href="/tags/database">database</a> connection. So we can use before, after, before each and after each hooks. So I'll give you five minutes and then we will discuss it together. Let's see if I can find the API that broke a lot of stuff. Before each should be renamed to before each once for each underlying block. Yes, that's weird. Yeah, I guess. But you know, you can also do this D, not before, if I'm not mistaken. You can also do this stuff. You can create nested hooks from the test context. So you can make the before each even more before each. Anything that makes just obsolete is a good <a href="/tags/workshop">workshop</a>. Yes, true.

Oh yeah, yeah, yeah. We will see a lot of very cool stuff later. Okay, let's see. Let's have a look at the result. So you can just create the variables. It's weird, no semicolon. I'm a semicolon fan. But let me know if you prefer semicolon versus no semicolon. But the point is that you can create a before hook and after hook that will be run at the end, beginning and at the end of the test feed. And then the before each which will create, it will instantiate the user, create a new user for the test and it will delete the user created after every test. This works, this approach, this very specific approach works for a test suite that's very simple. When things start to get complicated, you want to scope those hooks better and you don't want to use global ones. So as I said, you can scope test like this, create a hook here before and you can run the hooks only inside a specific test suite because you don't want to mix too many things altogether. Imagine that a test does not need the users so there is no need to run that before each hook for that test. And so on our very test, we can create them nested. When you create tests inside a test, you always need to await and then we don't need to have cleanup inside the test itself but inside the hooks. So it's very, very useful. This is an example, complete example. You can see we have the before to set up the <a href="/tags/database">database</a> connection at the beginning and at the end of the test suite and at the end. And before each test, we create and we delete the user. Yeah, I think this is pretty straightforward. This is the proper way to handle external objects being used in the test suite. So we don't put stuff inside the test because it will get messy very, very soon.Okay, so let's go to exercise number six. We have a few keywords for our <a href="/tags/nodejs">Node.js</a> test runner such as only to do and skip. So we can make the execution much easier. To be honest, only is a bit weird and we will see later why it's weird. But to do and skip are pretty straightforward. To do, it says it will run the test, you will see the output, but it will not count towards the general output. So if it fails, doesn't matter. Skip will just not execute the test at all and only will execute only a subset of test specified and it's useful for <a href="/tags/debug">debugging</a>. You should not use it in the life scenario. Let's have a look. So imagine that you are in the development phase of a new feature and we want to prioritize, postpone, or delay a bunch of tests. Sometimes I just comment things out, but it's not best. It's very error-prone to comment tests that we don't want to run. There is a typo here. So in index-test.js, we have four tests. So based on the requirements that are written inside the test, let's apply the correct keywords to apply the correct behavior. Okay. So as usual, let's go into a behavior field. <a href="/tags/npm">NPM</a> field. Okay, it's breaking because we are running some tasks that we are not completed yet. Let's have a look. So we have this function product that is not ready yet and will throw. So we have to make sure to skip it or to do something that, like, it's still a work in progress. We want to execute only this very specific test. This task is not meaningful. It's still a work in progress. And this one runs normally. So let's use the proper hoops to run the test as described in the comments. Why use skip instead of to do? No, throwing in a to do, throwing does not affect the output. So in a to do test, if it throws, you will see the result, but it will not matter. And this is useful because sometimes you want to see if something passes or not, but you're not sure because you're still working on it. So you don't want to affect or imagine you are collaborating and you're doing some TTT test even development. So you create the test. So you want to make sure if the test passes or not, but you will not to impact the general test fit. So you mark it as to do. With skip, you don't execute it at all. So you don't know if it passes or not. So they have a slightly different use case. So skip is for tests that you know will fail and it's pointless for them to take time. Especially if they are heavy and not bad. Exactly. Yes, so skip it will not execute them at all. Now, let's have a look at the solution. So we can skip the first test. We can skip it because it's meaningless even it's not ready yet. So even if we see the result, it doesn't... like the result would always be an error.

It will always throw. So it doesn't make sense. We want to execute this specific test. So we need the only keyword. Test is not meaningful. So it's still work in progress, but it doesn't throw all the time. So we can mark it has to do. And this one shouldn't run normally. So we don't have to do it. So on this point, I will just mark that. If you start with the option dash dash test only, it is possible to skip all the top level tests except those that are marked on. This is something that I don't personally like. This is a behavior that I don't like. Let's have a look here. Like if I've write something, if I mark something as only like in the solution in number six, I expect it to be the only one that is run, but that's not true because we're not using this option. I think that it was a PR to change this behavior, but my opinion is very confusing. Like I will link it in chat. What do you think? Do you agree with me? Like that you need to pass a specific flag to run the test only. So I find that I don't really like it. Like if I use a marker test as only, you should run only that and not other tests at all. So yeah. Just wanted to let you know about this behavior. I don't know why, what's the reason behind this choice, but it's a bit weird. But the only keyword by itself will not do it. Now in other test runner, if you use the only keyword, it will work as expected. In this case, you need to use the only keyword and test only flag. Anyway, so that's like, that's something that you wanna know in before.

Okay. Any other questions before we start with number seven? What's the difference between test only and test only truth? Same thing. There's literally no difference. Like a lot of the keywords, you can pass them in as objects inside as the second parameter of test, but there's no reality for us. All right. Ready for number seven.We have mocks. I really like mocks. It's one of my favorite topics because not many people know that <a href="/tags/nodejs">Node.js</a> has a very good mocking library. So if you are used with mocks as a <a href="/tags/testing">testing</a> technique, so you can create a fake version of an object and use it to control its behavior. And <a href="/tags/nodejs">Node.js</a> mocks provide both stub functionalities and spy functionalities. So they are like, they are two in one. You can check if the function has been called with which parameter how many times, but you can also create a fake function that does something else. It's very good for like, imagine that you have to call some third party API, but you don't want to do that. So you want to mock the implication to the third party API, so you don't have to rely on external sources or complex setups. If you are used to integration test, you know how painful that is. So mocking is very important, but like it's also important not to abuse of mocking because then you go in production and everything's different. So <a href="/tags/nodejs">Node.js</a> offers a mock function that provides the spy, stub, replace behavior. It's very cool API and we will see it together. So as usual, we go into directory and we create a function. We see that we have functions that interact with external system. So we want to mock some implication.Let's go into the source <a href="/tags/code">code</a>. Okay, and zero six, and zero seven. Okay. Pass. So we have, okay. Let me to do a bit of movement. I got to remove it here. Anyways, so we have a functions spy sum that we've used also in the previous example, can import from source. So you can use the mock function, try to play with it and see how many times it has been called, like you use it and you check how many times the service has been called, which argument and which error has generated. It will be a function, it will be a spy. This is a very common use case of the spy function where you can monitor the test <a href="/tags/code">code</a> during the test execution. And it will provide a lot of features so you can also log the output. If you need <a href="/tags/documentation">documentation</a>, you can find it here in mocking. I will post it in chat. So you can find all the <a href="/tags/documentation">documentation</a> on mocking in the JS. And another cool feature is that you can also mock. Oh, it's in the next exercise. I don't want to say anything, but you can mock timers. You will see later how that works.

As usual, if you have questions, problems, my window machine has given me blue screen, blah, blah, blah, I didn't check, but if you have blue screen, I don't think you will be able to write it in chat anyways. I don't know if you have noticed, but with test runner, we can already move a bunch of lab external libraries. I always find it hard to write tests for event driven things, tinkering around with time mocks is tedious. Yeah. Mocking timers, it's very painful. And it makes tests very flaky. So, something that you'd have to be very cautious with. But you will see, with the next exercise, that it's specifically about timers, how much easier that is. It's still painful, but the test runner makes it easier, I believe.Okay. Five minutes and we will see this. Okay. We're also getting very close to release node 22, which, by the way, will contain a new version of VA. Probably will contain VA. I will entertain you while you do the exercise. So, don't mind me. It will contain a lot of cool stuff. See if I can find a change log. Oh, yeah. By the way, it will contain something like promise with resolvers. See what other features that will land in node. So, a bunch of, yeah. If you want to see, I cannot find a proper change log for VA, but this is one of the features that will be released in the next <a href="/tags/nodejs">Node.js</a> version. It's a big one. Wow. So far so good. Any blockers? Any issues with spying? I think the <a href="/tags/documentation">documentation</a> is quite easy. You can have, you can wrap a function with mock.fn and you can do some stuff.Okay. Couple of more minutes. Okay. Let's move to the solution. So, you can basically wrap a function. That is in this case, it's sum with mock.fn. You can import mock from the node test. You can mock it. Once you've wrapped it, you can check the behavior and you can make sure that the number of calls are beginning zero, we call it once, and the number of calls becomes one. And we can also inspect every single call to see what are the call arguments. And we will make sure that are the same, that are passed here. We make sure that the result is seven, so the correct one. We make sure that there is no error, but if it troubles, you can also make sure. So, this is extremely powerful and it's out of the box of <a href="/tags/nodejs">Node.js</a>. So, when you install Node, you already have all this very cool stuff. I personally love it. Like the idea to have all these things out of the box. And at the end, you only need to remember to reset the mock. And so, you're not altering other tests on the same function. But yeah, this is one of my favorite features of the <a href="/tags/nodejs">Node.js</a> test runner.

What do you think? Is the node test runner able to handle TS file natural or does it need node-tsc? What about alias path inside this config jest, blah, blah, blah, and its... Uh, okay. There is a whole exercise about <a href="/tags/typescript-libraries">TypeScript</a>. So, if you repost that question later, it will be much easier to answer it. So I don't spoil anything. So, as you can see, mocking, I love it. Okay. I love it and you should be all use it. It's very cool. That's a very cool feature. You can always check the solution here and you can import test here, blah, blah, blah, as we discussed. So, yeah, mocks are timers. This is something, as I said before, it's very painful having time-dependent functionality like the bouncing, throttling. It's always, always painful. So, with a question, I haven't mocked anything very complex yet with the module. How has your experience mocking complex classes been? Been great. You can mock almost anything. The only thing that now you cannot mock are imports. And that's something that we are working on, but it works just fine, slowly. I think you should definitely try. So, timers, they are a bit unpredictable. They always make results very, very unpredictable. Mocking packages like Axios is currently possible. You can mock, you can wrap the Axios function inside the mock. You cannot mock the import itself. Like if something is required, like you're <a href="/tags/testing">testing</a> something and that something imports Axios, you cannot change the import dynamically. But if you test the function directly, you can do it. So, talking about mocks, the <a href="/tags/nodejs">Node.js</a> test runner also offers timers mock, so you can mock the timers. You can control the timers very easily. So you don't need to use real timers, like real timers function, like set them up and set the interval. I strongly suggest you never use real timers inside your test. They will make the application extremely flaky, especially if you're running tests on <a href="/tags/github-actions">GitHub Actions</a>. <a href="/tags/github-actions">GitHub Actions</a>, the way they work are very different from, they have a virtual file system, they have, the network is very different. So you will run into a lot of timeouts, a lot of issues if you use timers. Do not use timers in <a href="/tags/github-actions">GitHub Actions</a> for tests. They will become flaky 100%. And I know this because the <a href="/tags/nodejs">Node.js</a> <a href="/tags/ci-cd">CI</a> is so flaky. It's extremely flaky, and most of the time it's because of timers. So don't use it. So let's see if we go to the <a href="/tags/documentation">documentation</a>, we can see that we have mock timers class. It's still experimental, and allow you to mock timers. You can access it by mock.timers enable, and you can choose which API is to mock, like setTimeout, setInterval. I will copy paste it in the chat. And, as usual, we will mock setTimeout. Let's go in, success number eight. Okay, yeah, we have the, hey, the mock timers API is experimental, but it's very good. It's very good experiment. Okay, so call function with a mock callback and a delay. Imagine we have function called delayed hello that we import from here. And let's spy on how many times it's been called. And after the delay, we spy it again and see what's the proper behavior. Okay, five minutes and, we will back and see the mock timers. I want you to experiment a bit, play with it. And if, like, I want your feedback to see if the <a href="/tags/developer-experience">developer experience</a> is good enough. These features have not been tested a lot by users because they have not been, like not many people use Node 21. But I would like you to give me your honest feedback and, like, how we can improve the <a href="/tags/developer-experience">developer experience</a> on all this stuff. So, yeah. As usual, problems, questions, whatever, ask in chat. I also made a PR on timers recently. Let me see if I can find it. Uh, uh, uh, close on node. We have timers, no. Yeah, I did a PR to mock timer. Basically, now mock timers behave exactly like the time of glass. So they are much, much more similar to the real timer object, before they were a bit different, so. Cool, cool stuff. Will the new stuff added to the strand in 22? If yes, which new feature are you most excited about? Yes, all this stuff will be. So how does the <a href="/tags/nodejs">Node.js</a> release process work? So all the versions are, let's say, non-LTS versions. So not many people use the non-LTS version. So a lot of these features are ignored by most people.

But all this stuff will be available in Node 22, which will be an LTS. It will become LTS in October. And yeah, it will be very, very interesting. Which new feature I'm most excited about the test runner, or you mean about Node 22? Like all this test runner stuff, it's already in 21. So it's already available, if you want to expand. If you talk about <a href="/tags/nodejs">Node.js</a> 22, I'm writing, if you want, I can give you a little sneak peek of, wait, I don't have it with me right now. But I wrote the article, I'm writing an article for Node 22. The biggest feature that I'm most excited about is requiring ESM module. So now you can write, there is intercompatibility between Cjs and ESM. And basically, they just work out of the box. So if you're a library author, you will not have issues anymore. And another stuff that's very cool in Node 22, you will have a WebSocket client by default. You will have a glob object, so you can do pattern matching of the file system by default. You will have, let me think, Node.Run, this is a cool one. So it's not been released yet, so you will not know about it. Yeah, Node.Run is cool. So, yeah, I will write the blog post and we'll see it published very soon on the release notes.With the <a href="/tags/nodejs">Node.js</a> test runner, you can mock timers and control them easily. Avoid using real timers in tests, especially in <a href="/tags/github-actions">GitHub Actions</a>, as they can cause flakiness. The mock timers API is experimental but useful. You can also mock packages like Axios, although you cannot mock imports dynamically. The <a href="/tags/nodejs">Node.js</a> test runner offers the mock timers class, which allows you to mock timers and choose which APIs to mock. Experiment with it and provide feedback on the <a href="/tags/developer-experience">developer experience</a>. There are also new features being added in <a href="/tags/nodejs">Node.js</a> 22, and the release process focuses on non-LTS versions.We're not done yet with the <a href="/tags/nodejs">Node.js</a> test runner. You can also mock dates, which is very niche but useful. If you need to simulate calendar events and ensure that time passes, <a href="/tags/nodejs">Node.js</a> allows you to mock dates. You can enable date mocking and change the time to a specific date and time. This can be useful when <a href="/tags/testing">testing</a> functions that use Date.now(). The test runner provides an API to set the date to a specific value and verify that it is formatted correctly. Mocking timers and dates in the <a href="/tags/nodejs">Node.js</a> test runner provides powerful <a href="/tags/testing">testing</a> capabilities for time-dependent functionality.

So yeah, this is the correct way to properly check for argument call. So yeah, this is an on 21 feature. I suggest you to use odd versions, because not in production, but on your machine, because they contain some odd features, and we always want feedback, and I need to remember to change this one. Otherwise I would forget. Okay, sometimes I review this one million times, but it will always slip some stuff, some errors. Okay, so yeah, this is a lovely feature. Do you realize how powerful this <a href="/tags/nodejs">Node.js</a> stuff is? Yeah, so this is a very powerful feature. Do you realize how powerful this <a href="/tags/nodejs">Node.js</a> test runner is? It has literally everything, and it's out of the box, like you get it out of the box, and I think it's very cool.So we're not done yet. We can also mock dates. And this is another of the very niche stuff that people usually love. So imagine that you have to simulate calendar events, and you need to make sure that time passes. Imagine that your function uses dateNow to get the current date. That is a pain. But <a href="/tags/nodejs">Node.js</a> allows you to mock all of this. Let's see how. Okay, does the link work for you? Let me know if the link I sent in the chat works for you. So let's try to, imagine we use a function that use dateNow, and we want to be able to mock it. We can enable the date mocking, and let's try to change the time to 2024, zero to 19, and verify that the time return is correct. We can use this API setTime to change the actual time, and verify that this is formatted correctly. As you can see, you can do context mock times, enable and unmock dates. As usual, we go into our source folder. Double-click. Mock dates. We are in npm-pid. Let's see. Okay, this needs <a href="/tags/npm">npm</a> run verified. And it fails because you need to call timers enable at least once. So we need to enable mocking, and we need to check that these two assertions are properly validated. So let's give five minutes, and then we will watch the results. So did you figure out how does the test, like this test, know that I haven't called timers enable at least once? There's no monkey patching, and the source <a href="/tags/code">code</a> that you've writed here is the same that gets run, so there is no, like, it doesn't get modified. Like, it does get modified a little bit, but like you just write a test, and it knows if you call the function or not. Do you have any idea how that works, or what sort of black magic is <a href="/tags/nodejs">Node.js</a> doing when you execute stuff? To know if you run a certain API or not. Do you recommend using odd node version in <a href="/tags/ci-cd">CI</a>? Yes. That's the best place to run, like run odd version in <a href="/tags/ci-cd">CI</a>, so you know if you, if when you update to the next LTS, your application breaks. Like, you don't use odd versions feature, but you just run it against the, in the <a href="/tags/ci-cd">CI</a>, so you know that it will not break with the next update. Okay, let's have a look at the solution. So, it's very good. So you can mock as APIs, we can mock date, and then we can set the date dot now to whatever time that we want, okay? In this case, we get new date and get time to give it two milliseconds, because now it returns the timestamp. And then we can just run our functions and check the date is the one that you expected. This is incredible, if you're writing something that's date dependent, very, very, very cool, and you don't need external libraries. This, it's all inside <a href="/tags/nodejs">Node.js</a>. Any questions? Like, I love this feature, to be honest. I don't know about you, but this solves a lot of headache and a lot of external libraries, because you need one library for the timers, you need one library for the dates, you need one library for this, one library for that, but this solves everything. You have all the tools, and we will see later with <a href="/tags/typescript-libraries">TypeScript</a> and with <a href="/tags/code">code</a> coverage.Going to the next exercise, we have a reporter. So reporters is basically what creates the output of your test runner. So when you run the test, you want to be able to consume the result. They transfer the raw test output into a readable format. A readable format can be text, can be <a href="/tags/html">HTML</a>, can be JSON, can be YAML, can be XML, whatever you prefer. Depending on the output, it's more human readable, or it's more machine. <a href="/tags/nodejs">Node.js</a> offers, by default, the four test runners, the four test reporters, which is spec, it's the default one. Then dot, which is like a dot, if it's okay, and an X if it's not, it's like the list of variables. Tap, which is machine readable and JUnit for all your XML lovers, Java, Java style. So in this problem, we will create a custom reporter, because obviously you can create your custom reporter, and there are a lot of reporters that are created by the <a href="/tags/community">community</a>. So let's look at the folder. Go into, into reporter. Okay. We will see that we have, we want to be able to return a champagne pop when we succeed, and a bug when it fails. You can run it with this comment, and it's very long, so we'll just post it here. So this, I promise, that's the test runner. It failed because we are not returning anything, and this is a, an async generator function. So the source, we can, the source is on a iterator itself. So, copilot already prompts me to, do some <a href="/tags/code">code</a>. Source is an async iterator. You need to iterate over it and yield the result. If it's a, if it's not an error, champagne, if else, a bug. I'm getting an error that the date is one day before. Can I have to do, what time zone are you in? Yeah, probably also has to do with international, <a href="/tags/internationalization">internationalization</a>. It has to do with <a href="/tags/internationalization">internationalization</a> with the way the date is.

Now, I think because in your time zone, this date is probably considered, maybe it's, I don't know. See what this does. But yeah, I think it has to do with <a href="/tags/internationalization">internationalization</a>. But, so, I will, I will look into it. I will make a test by, my colleagues in U.S. And see, when Brett does Multitool. Okay. Okay. So, Are you having fun with the Async iterator? How many, how many times have you used Async iterator in your day to day? So we can do, or wait, no, no, no, no. Wait, let's go to tools. Wait. Oh yeah. So yeah, some stuff. So, okay. This will break honestly. We see that we have a bunch of types so we can switch on. Case, no, that's, but case... Have test. Error, some note mistake. And new output. We yield a little bug. Okay, these are all the, we have test, pass. So in case of test case, test pass, we return that champagne bottle. And in case of test fail, I think it's test fail. We return the little bug. And we can just run it and it returns some champagne because all our test passed. So it's very powerful. It's very cool. You can write your own. You find that quite handy using readable in pipelines, true? Yeah. You can use the pipeline. Like, I think it's a good thing that Node is moving to iterators, like from streams to iterators. We recently started supporting the resource in pipelines. And so it's a very good thing. I love iterators and sync iterators. I think that's the more modern way of handling <a href="/tags/javascript">JavaScript</a>. So, were you able to create the test reporter? Imagine how many things you can do with this. Like, if you're, if your, there isn't a test output that's supported right now, you can create yours and see all the events that's going on on the test runner. So test pass, test start, the agnostic, blah, blah, blah. Cool. So, as I said, the solution is very simple. We receive source, which is on a sync iterator, we iterate over it, and we yield the success or fail, which are those two values. Questions? Can I go to the next one? Are you still alive and kicking? If I'm boring, let me know. This is very important. <a href="/tags/typescript-libraries">TypeScript</a>. We finally arrived to the <a href="/tags/typescript-libraries">TypeScript</a>. So Node will never run out. Like, never say never, but probably never run <a href="/tags/typescript-libraries">TypeScript</a> by default without the use of a transpiler. Like, as an external dependency. I think this is a good choice because having things put in by default and like, it's better. I think that it would be better for <a href="/tags/developer-experience">developer experience</a>, but it's not a smart choice in terms of software <a href="/tags/creativity">design</a> because today <a href="/tags/typescript-libraries">TypeScript</a> is the coolest thing, tomorrow CoffeeScript is the coolest thing, and so on. And also, like, what is <a href="/tags/typescript-libraries">TypeScript</a>? <a href="/tags/typescript-libraries">TypeScript</a> is a thing defined by a TS config. Adding a default TS config means enforcing <a href="/tags/typescript-libraries">TypeScript</a> version on people. So I think, like, you should sacrifice a bit of <a href="/tags/developer-experience">developer experience</a> to leave freedom to users, whatever <a href="/tags/typescript-libraries">TypeScript</a> version they want, whatever transpiler they want, whatever TS config they want. But this is just my opinion. So, but the <a href="/tags/nodejs">Node.js</a> test runner actually supports <a href="/tags/typescript-libraries">TypeScript</a>. You just need to use a transpiler, like a tsnode or tsx, and run a dash dash import. Yeah, so it's very useful. You can actually, like, you can run <a href="/tags/typescript-libraries">TypeScript</a> with Node. It just requires a small flag. I don't think this is too painful, to be honest. It's still an experimental feature, and as this little note here says, the flag, if the flag is provided several times, the module will be executed sequentially in order to appear. So you can mix and match many transpilers. Like, you can make, take your <a href="/tags/typescript-libraries">TypeScript</a> and turn it into, I don't know, you can transform your <a href="/tags/code">code</a> however you want, for all my CoffeeScript friends, users. Yeah, yeah, that's the cool thing. You can use whatever transpiler you want. You want to use tsimpler, you can do that. You can, you want to use swc, you want to use whatever. Like, it's your choice, and I think having a choice is much more important than, I don't know, like, writing just Node index.ts without knowing what the hell is happening to that. But anyways, so let's try to run this index.ts file, and we will use the import flag, as we discussed before.

It's usually. No? Okay. Okay. Have a look at the source <a href="/tags/code">code</a>. So we have test folder, we have test file. Oh, unknown file extension, by default, Node doesn't know what <a href="/tags/typescript-libraries">TypeScript</a> is, and will tell you that it's an unknown file extension. But, if you use import tsx, or import tsNode, or import whatever transpiler you want, you can run it very easily. Okay, so the issue is, this is an issue, is that you will need to specify that you're running ts files, because by default, they will be ignored. And boom, it works. Because by default, it will look at files with js extension, and this is something that I can change, probably I can improve. So that you don't need to specify the folder with the extension. Let me know what do you think? That's something I can improve. Here's the <a href="/tags/documentation">documentation</a> from, what is, import. Wait a second. Dash dash, dash dash import. Okay, here it is. Okay, still experimental, added in Node 19. You can use dash dash require to load the common js module, and dash dash import. Yeah, it feels odd, as normal Node test looks for test file instead of not running anything. Yeah, that's true. That's because of the file extension, but I think I can open up PR to change that, I don't think it's a big deal. I will see, I will improve it. Other than that, you can find the <a href="/tags/documentation">documentation</a> on dash dash import here. You can use this to run also, like not necessarily with test runner, but with Node itself, to run <a href="/tags/typescript-libraries">TypeScript</a>. All right. We have now, number 12, we have test coverage. So test coverage, well, I think we are all familiar with test coverage. Tells us the, how much <a href="/tags/code">code</a> has been covered by our test, and allows to identify black paths that has not been covered. There are multiple types of test coverage. We have statement coverage, function coverage, line coverage, branch coverage. There's, like, so many things that you can cover. You can check for coverage, but you want your, you want to be able to see, usually, with branches of your <a href="/tags/code">code</a> has not been tested at all. So this feature is still experimental. I want to talk, before we go to the exercise, I just want to, like, are you all familiar with Istanbul? Not city, the library for <a href="/tags/code">code</a> coverage. <a href="/tags/npm">NPM</a> Istanbul. Okay. This is a quite old one. Oh. It's actually deprecated. Okay, fine. It was deprecated. But yeah. It still has an insane amount of downloads. So probably the reason why it has been deprecated is because, oh, maybe it moved somewhere else. So the reason why it has been, like, this is not, this is still the way to do <a href="/tags/code">code</a> coverage. It's because before what Istanbul would do is to take your <a href="/tags/code">code</a> and insert some counters and functions to check if the <a href="/tags/code">code</a> has been executed or not. But nowadays, V8, which is the <a href="/tags/javascript">JavaScript</a> engine that runs behind <a href="/tags/nodejs">Node.js</a>, offers an API for embedders to check <a href="/tags/code">code</a> coverage internally, and that's much more precise and powerful and also fast. For example, C8 is one of the most common <a href="/tags/code">code</a> coverages because it's, as it says, Native V8 <a href="/tags/code">code</a> coverage. So it's very fast. It's very precise because it's basically V8 telling what's executing or not. You're using Clover, which I've never used to be honest, but I will look. No, it's not this one. But yeah, if you have a link, send it. But the cool thing is that <a href="/tags/nodejs">Node.js</a> uses the same V8 API, natively so you don't need the external library to do test coverage. So in this very simple exercise, we will try to reach 100% coverage. So. And then I will tell you a bit of a funny story. So we have all the three functions. We have the three functions if we're on MPMP. Not this one. We need to run this <a href="/tags/code">code</a> here. I should probably add it to the <a href="/tags/cli">terminal</a>, to the script. Okay, we will see that the line coverage is 82%. We have uncovered lines. So let's uncover, let's cover them. So any reminiscence of this table should be removed by now, yes. And for the NYC it's not really needed. No, we can do everything with <a href="/tags/nodejs">Node.js</a> itself. We don't need any other external library. Yeah.

This is the command line tool. You don't need anything else. Yeah. With Node 22, you can remove so many dependencies from all Node projects. You can remove chalk, you can remove.env, you can remove C8, Istanbul, or whatever, like whatever <a href="/tags/testing">testing</a> library. You can remove test libraries, you can remove so much stuff. Like you don't need 100 packages to do the simplest thing. You can do it all by default.So let's have a look at the solution. It's basically adding a bunch of functions that were not covered. I probably should add here the hint. Yeah. But also if you change the reporter, it will also change the... That's the reporter. Or the j... For example. It will also change the... Build, I guess. Okay, here we have this coverage. In jUnit we don't have this coverage. In tab we have this coverage. Okay, that's funny. I think I found the bug. Yeah, I didn't know about... Oh, open Clover. Yeah, I didn't know about this, but I will check it out. Just let me write that. We have a bug here. JUnit, I'll give the tag in. Find, finding when you find bugs while doing work. See the jUnit. I'll just block it. It doesn't work. That's probably the issue. Okay. Yeah. So that's a very cool feature. I suggest you to use it. It's still experimental. So probably do not run it in production, but I think this could be something. Oh, I have done a PR in the past. The tab closed. Let's see. Organization load. And I wanted to do coverage. That's not here. Let me find it. Okay. So I wanted to implement the test coverage threshold, like check coverage to make sure like if you want the 100% coverage, you would be able to do it. If you didn't reach coverage, it would crash. And it would exit with error, but this was closed and it was not matched because of source maps, because the current test runner does not support source maps. For example, if you use <a href="/tags/typescript-libraries">TypeScript</a>, so it was not deemed ready to go in production. Yeah. But I tried my best to improve the test runner. So what's the estimate, the ATA on this time being completely ready for production? It is already production ready. This comes to the stable and this production ready. It has a few bugs on the experimental feature, but for the stable feature, it's ready. So you can use it right now. What's the best way to integrate no <a href="/tags/testing">testing</a> to this core test tab? The only thing I found is a corner, blah, blah, blah, which looks good, but doesn't look like it's used much. To be honest, I don't know because I don't use the test tab in VS <a href="/tags/code">Code</a>, but if it's something that it's very important to you, I can ask my company to, if someone wants to, to develop something similarly because we try to improve the test runner. We do some support. And this is something that I probably have proposed. It's probably something that's been proposed in the past, but nobody has championed it. So if it's something that users want, you can open a feature request on, I don't know. Okay. This is not just related to, it's more a plugin. Okay. Don't worry. I will see if I can make it happen. This is something that interesting.

Okay. Here's the solution. You just need to add a bunch of lines that were missing to get 100% coverage. Finally, we have watch. Watch mode. So NGS supports watch mode by default. So if you were using nodemon, you don't need it anymore. So in watch mode, you can watch a specific path or... Sorry, I have a question. Isn't this <a href="/tags/code">code</a> working together with nodemon general protocol for <a href="/tags/testing">testing</a> and should not be looking to not test, blah, blah, blah. I have no idea. They should, and yeah, they do look into the back of <a href="/tags/cli">CLI</a> because they can just read the output that we saw before with an async iterator. But I have no idea what's going on with this <a href="/tags/code">code</a>. So I'm not the best question, the best person to ask this question.Let's get back to watch. You can watch for files being changed as your <a href="/tags/code">code</a>. So if there is, like if you are all familiar with nodemon, it does the same thing. And you can also do this with testrunner. So as you develop, you change things, you run the same test to make sure that that's passes. This is very powerful. And you can do this with the dash dash watch flag. So let's see what this example, example number 13. Run the <a href="/tags/cli">terminal</a>, not test, dash dash dash watch, and see if it will do. We do not test dash dash watch. Okay, so we are watching test index TS. So if we remove the comment. We can see tests being executed. Okay, I removed the comment here. And tests are being executed. I removed comment. Tests are being executed. I remove something that's gonna be executed. And it crashes. Okay. This is extremely powerful. And also from node 22, is this feature is considered stable. So this is something that you can use by the, you can use, without worrying about experimental feature in node 22. Very cool, very cool feature. If you need <a href="/tags/documentation">documentation</a>, you can find it here. Watch. Dash dash watch. You can read here about all the stuff. It's what's well with test runner.So I guess, yeah, that was it. So I wouldn't just ask you one. One favor. So with this QR <a href="/tags/code">code</a>, you can have access to my social, my GitHub. So if you want to know about more stuff, you know about <a href="/tags/nodejs">node.js</a> and also the open source libraries that I had maintaining like Express or <a href="/tags/fastify">Fastify</a>, feel free to write me. Oh yeah. Upgrading, and just upgrading to node just 22 brings in a lot of features in an NTS version about the test runner. So you definitely should update. How will this influence the node sites and bundle sites of production now? This is a very good question. Yeah, obviously the more <a href="/tags/code">code</a> you add, the more, the bigger the bundle is, but I think, unless you add an external dependency, I don't think it makes that much of a difference. And also we try to be very careful on the <a href="/tags/code">code</a> that we write for example, we had to change an implementation of.env because now we should.env, not.env itself but the same feature in core and the implementation was too big. So we had to resize it not to increase the bundle size, but yeah bundle size is it. With time it's getting a bit bigger. Yeah, but I don't think that's such a big deal given that <a href="/tags/nodejs">node.js</a> runs on servers that have memory, enough memory and enough space to run node. I will also do run on a smart OS, a non-smart, so maybe on that spike, it's a bit different. Any other question? I find it a bit confusing in the test runner that when asserting Booleans, when one test fails, it says something like true expected false. I have some tests that do when searching like this is a bit confusing exactly which but it should tell you in which line it failed. So that will be helpful and also it depends a bit on which test reporter do you use. If you like, if you use stuff, it should be a little bit more verbose and it should be more helpful. And well, thanks a lot to Node Congress for hosting me and giving me the opportunity to run this <a href="/tags/workshop">workshop</a>. And I guess that's it. Thank you everyone and have a good day. Bye-bye.

Node Congress

Node Congress 2024

Mastering Node.js Test Runner

Dominando el Ejecutor de Pruebas de Node.js

The Node.js Test Runner is a powerful tool that improves developer experience and standardizes test syntax. It offers features such as test discovery, organization, reporting, and integration support. The runner allows for running tests by name and in specific folders, and provides various assertion methods for code validation. It also supports parallel testing, sharding, and the creation of hierarchical test structures. Additionally, the test runner includes mocking capabilities, TypeScript support, and the ability to control test execution. The upcoming Node.js 22 release will introduce new features and improvements to the test runner.

Node.js test runner is modern, fast, and doesn't require additional libraries, but understanding and using it well can be tricky.You will learn how to use Node.js test runner to its full potential.We'll show you how it compares to other tools, how to set it up, and how to run your tests effectively. During the workshop, we'll do exercises to help you get comfortable with filtering, using native assertions, running tests in parallel, using CLI, and more. We'll also talk about working with TypeScript, making custom reports, and code coverage.

Marco Ippolito

JS Nation

I’m attending JSNation – the main JavaScript conference of the year. You may join me there for free with 10k other JS engineers and 40+ great speakers. Just follow this badge. 

#javascript

JSNation 2024

C3 Dev Festival

Join me at C3 Dev Fest, a contemporary software engineering festival!

Register to win an all-paid trip to Amsterdam. Elevate your career with industry experts and workshops & rock 3 dance stages at the after-party!

C3 Dev Festival 2024

React Summit

I am attending the biggest #Reactjs conference remotely. You may get a limited free ticket (50% of talks, no workshops) and join me by clicking this badge.

#react #reactjs

React Summit 2024

TechLead Conference

I'm attending TechLead Conference 2024 – get your free remote ticket and join me there

TechLead Conference 2024

React Advanced

React Advanced Conference 2024

Productivity Conference

Productivity Conference 2024

JSNation US

I’m attending JSNation US. Join me there for free with 10k other JS engineers and 50+ great speakers. Just follow this badge.