Check out a free preview of the full Polyglot Programming: TypeScript, Go, & Rust course

The "Testing in TypeScript" Lesson is part of the full, Polyglot Programming: TypeScript, Go, & Rust course featured in this preview video. Here's what you'd learn in this lesson:

ThePrimeagen demonstrates how to create and run tests in TypeScript and what a thrown error looks like. Suggestions for the amount of testing that should be done on a project are also provided in this segment.


Transcript from the "Testing in TypeScript" Lesson

>> I know we kind of blazed through that last part right at the ending, blazingly fast as they say. And so we're gonna kinda go back and we're gonna test each version of the config we created cuz there's a little bit of tricky logic there plus you get to see how testing works in every single one of these languages.

I will be trying to use just the most vanilla version of the testing available which means that I won't be doing any additional installations for TypeScript other than jest as or TypeScript doesn't have testing inherent. So you have to install something. For Go there are good assertion libraries, that make things a lot easier.

We're just simply not going to use those, and of course, for Rust there is some like pretty print assertion macros that you can use, we'll just be using what is available. All right, so let's just get started. I think it'll be a great time. So let's jump back over into, we're gonna start off with Typescript, should be pretty easy.

All right, so let's add some tests. So we do need to do this first, so let's start with this. By the way, I did have some errors when I was doing this just like a week and a half ago. There's this whole just 28 vs TSGs. And there are some problems.

So if for whatever reason you're running into a goofy problem, just try going into your package.JSON and turning 28 into 27 reinstall stuff and see if that works out for you. So I'm just gonna start off with this of course, jump over to TypeScript. Add an extra one of these.

Paste in, there we go. Should take a moment. See, you can tell this is real things. It took a moment. All right, and it's just init. And of course, let's see, do you want to do this? Yes, I do want testing. Yes, I do want TypeScript, yes, it'll be for node.

I don't care about coverage. Make sure you use Babel. Sure, why not clear all the mocks, I don't think that's gonna hurt us at all. So there we go, we're not gonna use mocks awesome. We have everything done and now created a nice little testing config for us.

So let's just make sure that everything worked swell and let's create a test subdirectory that's kinda the shape you want for jest, that's kinda the convention, right now in JavaScript. I've seen some other conventions recently where they've been putting the testing files adjacent to these files just having a.jest.ts in them.

I'm not sure if that's gaining traction or not JavaScript standards change all the time. Very hard to keep up but let's go config.ts and let's just make sure we can do, this is a test. Awesome, so this should work. Expect true to equal false. Let's have a nice failing test.

Make sure everything's working.,npx jest. And what do we get out here? Okay, awesome, everything worked out first try. Our init must have been successful, so I believe we are good to go, right? So long as everyone got to here, awesome. So let's get started, we'll just import our previous config.

And the only things I'd really cover in this kind of testing, kind of a quick note on testing, I think unit testing is always a good idea to do. You got to be careful about over testing, be careful about testing implementation details. I tried to always just test public interfaces, and I tried to pretend to be dumb about what's happening underneath the hood.

Because once you start getting a little too, once you get too clever by half, you start getting into the point of once you make some sort of private refactor, you start breaking unit tests all over the place. Because they they expect some underlying shape and can be a bit dangerous.

So let's go import, config or, I wonder if it can be auto imported, anyways who cares, config, are we I guess we call this get config, right? Well get config and we also have to handle the options and if I'm not mistaken, the options can just simply be an empty object.

So we don't really need to get all that information in there, so let's start off with a simple print all, right? So that's all I'm gonna do, now of course testing, we generate these special pass config and present working directory, I'm not gonna check on those ones because that means my testing has to go and like look up environment variables.

And eventually I write my own program for testing. Little dangerous, we're just gonna make sure that the operations and the arguments are exactly what I think. So we'll start off with config and go get config. Start off with a nice little empty object, I should be able to expect, config, operation, ellipses toEqual, Operation.

See if we can get it nice it's not getting imported in for me. No we're making fun of my LSP today by the way, everybody we're gonna have no LSP problems, I can feel it and of course you're gonna want to go in here and just prove that right?

Pretty simple test, I think we can kind of all expect like yeah, this is like our most basic operation which is just the print everything at your current directory operation. I'm gonna just take that paste it do the exact same thing, print key, pass in an argument, foo.

I believe it should be one of these, right? There we go. This should do the exact same thing, we should have the argument f print and of course of foo, awesome. And we'll do it again. We'll do something with add, and we'll do something with remove and we'll kind of call that good.

We're not gonna go into error expectations. We could do some error testing as well, but for me this is probably good enough because really the goal right here is just to kind of make sure everyone is a familiar what's available for testing. But also be to just always reinforce a good habit of at least put up a little bit of guardrails in your life.

Now I have had people argue that you shouldn't put up any guardrails. And it's an interesting approach to life. For me, I don't think I could emotionally handle that because I have dealt with too many code bases that are covered in no tests and finding bugs is very, very difficult.

So there we go, just did the whole ad operation. These are all obviously just happy path ones. Just like little happy test cases out there in the forest. I'm pretty sure Bob Ross would be very happy at this moment that we're doing that. There we go. And of course, removing only requires a single key.

So let's make sure we can remove the key, and this should end with a remove. I assume none of these things are kind of too wild. Let's make sure everything actually worked out, so I'll do an npx jest, added in a little extra character. There we go, we actually got a failed test, what happened?

Yes, this fun test right here. So what ended up happening is that, though we did init, jest config with TypeScript, I believe the preset did not do that. And I forget what you had to put here. But I wanna say you say ts jest. I wanna say that's what you have to do.

So, I think that's correct. I may have to Google it. Okay, there we go. We did actually [LAUGH] do the right thing which is kind of painful that though setting up jest and all that it doesn't actually quite do it. And so there we go, so we have a couple of errors right here, it looks like we actually did find a real bug, right?

I must have redefined path or something because it can't do this correctly. So let's jump back into our code, go back into so whoever bet on first try working clearly feels a little bit robbed right now. So did I have other paths out? Yes, so of course, this is just more crying in configuration, which is, if you don't have es module interrupt, I think is what the things called in your TS config.

You can't import one of these like that. So I have two ways of fixing it, either fix it in my ts config or just do that. So, let's just do that, why not? Just feels good, right? Just do a nice quick hack and everything should hopefully work out better.

We'll look at that. We found out that we have messed something up. So this is very, very excited. At least I'm very excited. So what have we messed up here? So let's go up and let's look at this adding key, removing key, awesome, as you can see right here, it looks like kinda goofed this up, right?

Obviously, our cases aren't quite catching everything and we are not doing an add operation when we expect it. So for whatever reason, we need to figure that out right now. So let's first just jump back in here. See if we can just spot it with a quick look.

Good operation, this all looks kind of like what I would expect it to, opts 0 is, here you go. There's the problem. I can't believe you guys didn't catch this yesterday. I feel like you should have caught this. I'm also a little surprised that TypeScript didn't throw an error here.

All right, I would expect it to throw a little bit more of upsetness here. I wonder if it has to do with the fact that I don't think I actually have a tsconfig.json. Let's just put an empty one right there. And we'll that's solve our problem. Cuz it's actually kind of funny that that didn't get shown up.

I usually program just expecting things to work. Yeah, so really I should be having args, right? I'm indexing 0 into an object which does not have that key. I must have done something in my config set up there. There we go, so that should make it so that we have the correct item.

We spotted the problem without doing anything. Everything else looks good. I'm a little skeptical at this point that everything is gonna work out fantastic. I was hoping that TypeScript would save me here and normally I feel like it does a great job. I must have something slightly off, but anyways, there we go, we got it.

Yeah, everyone happy? Everyone get it?. Everyone has the test going, I assume that the people in the audience here in front of Masters by the way, I'm not talking to random people, there's people right here. I assume you guys at least you're all familiar with jest so none of this stuff is too wild, right, okay

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now