Testing the Waters With Deno

Today, as introduced, we're going to be talking about testing in Deno. So first of all, how many of you write tests in your code today? Good, that's what we like to see. The rest of you, what are you doing? And I'm assuming you're mostly using Jest, VTest, Mocker, Jasmine, maybe? Okay, interesting. And while you were setting those up, how many of you remember the hell of configuring your correct TypeScript compiler, emitting the right source maps, and all the other chaos that you have in setting up your testing environment and your test runners? The nice thing about Deno is we've got this sort of batteries-included environment. Our approach to tooling is that it should just be part of your entire developer experience. So Deno has your TypeScript compiler, it has your testing, your linting, everything already built in, which means you can write your tests in TypeScript when you're using Deno. You don't need to do a whole load of configuration. So I know, you know, you're already used to testing, you've written tests before in usually, I assume Node. So I'm not going to do a big intro into what is testing and why should you be testing, but I am going to sort of talk you through the Deno testing tool. It's a slightly opinionated way of authoring tests. But if you're using something like Jest or Mocker, your tests will likely also run in Deno with very little changes.

So I'm going to assume that we have a computer that has already got Deno installed and I'm going to set us up with a very basic Deno project. So I'm just going to say Deno init, can you see this, by the way, is that big enough? A little bit bigger? Excellent. So what Deno init has done is it set me up with a basic project here. So I've got a main.ts, which has got a really basic add function, and I've got a main.test. So this is what we're going to use to write our tests in. Deno.test allows us to define our actual test cases, and what we've done here is we've imported our add function from our main.ts, and we've imported this assert equals, which is going to allow us to do some assertions. And we can do both anonymous functions and name functions if we want to, so in fact, let's cheat this. I'm going to just paste that in here. So we can also have a test with a named function. So here we're testing negative numbers. We can also do an ignored test if we wanted to, so sure, go on, Copilot. Nice. Okay, so this test is going to be ignored because we've used ignored true there. And if we want to run a test with multiple steps in it, for example, we can absolutely do that too. So let's test with steps. So what I want to do is I'm going to, in fact, I'm going to cheat this one as well and just paste it in and then we'll talk through it. So we can set up something that is going to run before all of our tests. Then we have our t, which is going to allow us to step through so we can define multiple steps that we might want to do in our test. And each step can have its own name and is going to be reported separately in our test results.

So why don't we try and actually run this. So let's run dno test. And we can see we've got some tests, some of our tests have passed. Our ignored one has been ignored and our steps have stepped through. So we can see here we have with steps running before all of our steps, step one, step two. We can see that we've done some nice steps through our tests.

If you're coming from something like Mocha or Jest, we also have the BDD style testing. So if you'd rather use something like describe and it, you absolutely can do that. So we can instead of our equals, we can use describe and it and before each. These are coming from the testing BDD library. These are part of the dno standard library, which is just a whole load of code that you will find yourself needing often in your projects. The standard library offers those to you.

Let's do, there we go. And we can also add expect. In fact, we need to keep our add in there, don't we? And this one is in the expect module. There we go. And then if we want to change up our test syntax, we absolutely can do. So we can do a describe instead. So we're going to describe our add function and we will say inside of here, it should return the sum of two numbers. Yep, that looks nice. Yes. Sure. And we can add in our negative tests as well. Here we go. Yep. Thank you, CoPilot. Okay. So these should be a bit more recognizable to you if you're coming from Jest or Mocha. And we can also use our before each if we want to. We can say before each, sure.

Put some text out there. And this will run before each of our tests. So if we try and run that again. What has CoPilot missed? What are you expecting here? A cozy curly? There we go. So very similar output to what we saw before. But perhaps with syntax that you're more used to using.

And we saw briefly the assert package earlier. So we can do a whole load of different types of assertions as well. So we can assert equals, assert array includes, assert almost equals. So we saw our basic assert earlier. I'm just destroying the stage. Don't mind me. But we could also do, for example, let's take it all the way back to our assert.

There we go. So we have our add. We can have assert in here. We could assert array includes. And we can... So we've seen that assert equals. We could do something like assert array includes in here. We could do assert throws. There's a whole load of different built-in tools in here for you. And there's an instance of... Missing an S. There we go. Nice. Let's try running these. Nice. There's also things like string assertions, type and Boolean assertions. Just here to help you write more expressive tests.

And there's things like assert almost equals to help you compare things like floating point numbers. As I mentioned, we have our assert throws, assert instance of. This comprehensive offering covers most testing needs. Typing Deno test repeatedly can be tedious, so the watch flag is available to monitor test changes and run continuously.

Using Deno test with the watch flag can help detect test failures, like missing array elements. Additionally, you can apply filters to skip specific tests based on keywords. Deno supports built-in code coverage functionality, enabling the generation of coverage reports. Running tests with coverage flag provides insights into the test coverage of main files.

For a detailed coverage report, Deno allows specifying a directory to store the coverage information. By utilizing Deno coverage commands, you can easily view the coverage report directly in the terminal. The flexibility to choose the destination directory for coverage reports adds convenience to managing test coverage results.

And you can also filter if you want to maybe skip a test. So I could say, for example... Let me put that back. Deno test minus watch. And then I could say filter. And I want to filter anything that has assert in it. And that's going to only run the tests that have the word assert in the name.

Deno also supports code coverage out of the box. So you can generate a code coverage report. So let's do that. Deno test minus minus coverage. That's gonna show me how much of my main TS is covered by my tests. So test minus minus coverage is going to run the tests and then generate a coverage report.

I could also do Deno coverage. Which is just going to display the coverage report in the terminal. We can also, if we want to, select a directory to save that coverage report to. So we could do Deno test minus minus coverage. And then our folder name for where we want to send the coverage to. It should have created a little folder for us. There we go. Which contains our coverage report.

And we also have support for JUnit style XML. If you would rather your reports are in that format. Useful for CICD pipelines and other tools that are expecting that format of coverage report.

I mean, we can see here that we've only covered 50% of our main TS because we've basically tested only the add function. We haven't tested this check for import meta. That's fine. We could improve our test coverage if we wanted to.

Deno also supports snapshot testing out of the box. Which can be useful for asserting whether or not your complicated object models are the way that you would expect them to be.

So let's set up a snapshot test. I'm just going to delete all of this. I'm going to import. Insert snapshot. From JSR colon sdd. Insert snapshot. Yep, that's what we want. And then let's cheat this one again because we're very low on time.

We got our... Nope. We're just going to set up a really basic object here. So we'll say, sure, that looks nice. And then we will do a weight assert snapshot. And now when we run our test, we want to establish that snapshot.

We will do Deno test minus R minus W, which is going to give us read and write permission. So Deno's going to be able to read the snapshot file, write to a snapshot file, and we will say minus, minus, minus, update. What have I missed? Testing snapshot. There we go. Cool, so that should have created some snapshots for us. And we can see in here that's created a snapshot. We would then, if we were running our tests again.

So maybe something changes in our object and we want to test whether or not that snapshot is matching. We would then say Deno test minus A, and we can double check that our snapshot is matching.

Okay, two minutes to show you an entire app in memory. So I know your tests are a lot more complicated than this. I know your apps are a lot more complicated than this. You want to be testing bigger applications.

So what we're going to do is I'm going to cheat and just drag in an entire app. So here we have a nice basic. This is just going to set us up a little HTTP server. We're using Hono to do that. Going to install Hono, hopefully. There we go.

Okay, just a super basic app, which is going to set us up an endpoint at slash weather, which has some weather information in it. And in here, we're doing some tests. So we're testing that we've correctly set up our HTTP server. We're testing that at the root, we get a hello world response. And we're testing that on the weather route, we get some sort of weather data. And then we're testing that on anything else, we get a 404.

So we can run Deno test in here. Oh, let's place that and place that. Let's try that again. And I have to run this with permissions because we're doing stuff over the network. So I just gave it the minus A there to get its permissions. So what we're doing here is sort of component testing, we're stepping through and testing that our little HTTP server is doing exactly what we expect it to do.

But we're dependent on this bit of weather data here. And we might want to maybe mock that up. And we absolutely can do that as well. So let's just jump into this example here. So we can instead, we can inject that weather dependency instead. So we will create a new file that is our weather service. This is where our weather data is going to be. We will inject that into our main TS. And then in our main TS, we can mock up some different weather maybe. So let's have a look. We can now create our fake weather service. And we can double check whether or not our app is going to work in the way that we expect it to if the weather changes, for example.

Awesome. So that's a very sort of, I'm going to say, ghetto approach to dependency testing. It's a very basic example. But I hope that this was sort of a whirlwind introduction to very simple testing in Deno. We didn't have to configure anything. We've got all our useful imports from the Deno standard library. So yeah, go and test with Deno. Oh, there's stickers up the front. So come grab stickers. And I also have a giant box of beautiful swag, because Deno isn't just a JavaScript runtime. It's also a clothing brand now, apparently.

We have a lot of questions for you. We don't have an awful lot of time. Oh, sorry. No worries whatsoever. There is also going to be a Q&A station downstairs after this. And they can find you there, right? All right. Let's get right into it.

What features of Jest and Vitest are not supported by Deno right now and might need a rewrite? As in, that Deno might need a rewrite of? That we need to rewrite. So I don't know. Take your pick. Who needs rewriting? I mean, the Deno test framework, I will fully admit, is not as fully featured as Jest and Vitest. So I absolutely recommend using those, but perhaps using them alongside the Deno testing framework. You know, they absolutely will work in Deno. So yes, I will admit there are an awful lot of features that are in Jest and Vitest that aren't in the Deno testing framework. All right. You know what you did here, right? By introducing that there are stickers and swag, this is going to be an interesting one. All right. How do module and package mocking look like? Or how does module and package mocking look like in Deno tests? It doesn't. It doesn't look.

It doesn't. It doesn't look. Yeah. Sadly, module dependency testing isn't really possible in Deno test at the moment. So yeah, the example that I showed is a super-duper basic example. But yes, you'll want to be using likely Vitest. Vitest is my fave if that's what you want to be doing. All right.

Maybe a comment for you. The official documentation page looks a bit fuzzy. Is there a better source to find more information? I mean, I feel like going to your talk would be a good place to get started. Come find me, the person who says it looks fuzzy, because the documentation is my pride and joy. I write the Deno documentation. So if it's not looking good to you, come show me what's not looking good and I will fix it up because... Yeah. All right. All right.

Just quickly going through them. Let's do one more question. So a certain complex nested object can become quite cumbersome in Vitest and Jest. Is it the same for Deno? It is. Yeah. Sadly. Yeah. Sadly. Yeah, I don't really have an answer... I wanted to ask what is the upside. All right. Cool. We'll do one more, just to make sure that we end on a high note.

Is there an easy way to rewrite a test suite from, for instance, Jest to Deno Runner? Is there any framework that is easier to change to Deno than others? Oh, you know what? I don't know which would be the easiest. There should be very minimal changes to run your tests in Deno. So TouchWood should absolutely run fine if you're using Vitest with Deno. If you're using Jest with Deno, these should all work fine. If you want to swap it over, obviously, there is gonna be a bit of editing to use the Deno test functionality. But yeah, I mean, maybe it's something we should think about for the future as a conversion tool, if that would be something that people might like. But it doesn't exist yet. All right.

Well, Jo, thank you so much for your talk again. My pleasure. Thank you.