Build an AI-Powered Fullstack Next.js App, v3

Mocking Functions & Testing Homepage

Scott Moss

Scott Moss

Superfilter AI
Build an AI-Powered Fullstack Next.js App, v3

Check out a free preview of the full Build an AI-Powered Fullstack Next.js App, v3 course

The "Mocking Functions & Testing Homepage" Lesson is part of the full, Build an AI-Powered Fullstack Next.js App, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Scott creates a test for the home page. To avoid testing the functionality of third-party dependencies like Clerk, mocks are created for the library's methods.


Transcript from the "Mocking Functions & Testing Homepage" Lesson

>> Okay, so now that we got that all the setup out of the way, we can write some tests. So there really is no right or wrong way to do this. You can co-locate your test next to your components. You can make a test folder in the app directory.

You can put underscore in front of it so it's ignored by Node.js. I'm just gonna just put it on a route, call it tests, keep it simple. Oops, not a file but a folder. Cool, so we have tests right here on the root. And then let's make a tests for the, what's a simple one?

How about the homepage? It's simple but it's got some auth in it, some async stuff, so we can figure out how to get around that, but simple enough to where we can try this out. Let's do that. So I'll make a new file in here, I'll call this, home.test.tsx.

And there's still some setup left. [LAUGH] Still got a little more setup and this is where I was banging my head, okay? So I don't know if you've ever used testing library before but these are common render and screen. And then this was one of the first signs that I've ever used, vitest.

So I've never used a V thing before, but I guess if you use it before it seems cool, I think I'll be using it going forward if it matters to anybody. And then we wanna import our homepage so I'll just call this like the homepage from app page.

So we got our homepage here, and then from there before we tested our homepage has these third party modules that it imports, right? If we go look here it imports next link imports clerk the next link one's fine because it's just a component. But this auth from clerk this is doing something and we don't really, I don't wanna test this I just want it to go away.

So we can mock that out. And the way that we can mock that out with vitest is using vi.mock, you can mock out an entire path to a module and you can just return an object that will mimic the object you would get if you imported this path.

So that's what we're gonna do. We're gonna mock out the auth, we're gonna mock out clerk provider coz that's in the layout. We're gonna mock out use user, we're gonna mock out a lot of this stuff. So let's do that. We can say vi.mock, we're gonna mock out clerk/nextjs.

It's a function and honestly, we can just return an object here like so. And then we want to mock out something called auth. That's the same auth that is being used here. We wanna mock that out, it's gonna return our new function that we have ourselves. It's an a sync function, so we'll just return a promise that just resolves to some fake user ID coz that's really what we're using it for.

So I'll just say new promise. Like this, resolve some user ID of whatever, like that, there we go. So we got auth mocked out. And then we want to mock out the card provider. Probably don't need to, actually, I think the off depends on that. So I think that's why I decided to knock it out, even though it's only being used in the layout file, which we're not importing and testing.

I think auth depends on the clerk provider being there, so we have to mark it out. So mark that out, I mean that's really, we just need to make a fake component that renders its children that's what a provider does. So children and, a div here has its children.

All right, getting skin somewhere and then the user one I don't think we use this so I'm trying to think why did I put this here? I think I had a problem this the one that I got I had to go look up all this stuff that was happening and clerk, so I think I had it for some reason the way clerk was importing, exporting stuff this was getting in the way.

So you have no I don't think we use this hook coz we don't do any client side data checking. I had to mock this one out. So I'm just gonna mock it out, use user a function that returns an object. I just got these properties on them, so actually just going to copy them so they don't really care.

So fake user is signed in true or false doesn't matter, these values don't matter. The next one is this mock is here just in case you wanna test the layout. I think I was testing the layout at one point, and the layout uses this font function next font Google and that was causing problems so I just marked it out until it go away.

So I did that, but I don't think I'm using the layout anymore. If so we'll add this, if not, not a big deal. Now we can make some tests. I can say test this homepage like so, it's async like this. Really all I have to do is render the page and I can await the page being called not that, the homepage.

Now once that is rendered, now I can do my screen. So I can say expect(screen), what's a good one? Yeah, getByText, I think that one's good. So screen.getBy text, what's on the homepage? We have tracking your mood, or something like that. Maybe we really care if that's on the screen to be truthy.

So we just expect screen by get text to return some element, and if that is an element, that's truthy. So if we set everything up correctly, we got one more thing to do. We have to add a command for our test. So if we go to our package JSON, make a new command in the scripts, call it test, and then you could just say, vitest.

And then we can just say NPM test and see if this works or not. Cool, okay, so it looks like it did render though, that's great. So it looks like our test is just bad, which is so good. So they were just so this worked the first time, that's so good.

Yeah, it just didn't find the element, right? So I'm guessing getBy text doesn't, I look deeply into that. So let's pick a different let's say get started. Cool, get started and I passed. So once once you render this page like this, you can pretty much do whatever you want at this price, just regular call assertions with excepts.

You can do snapshot testing, however you wanna do it. This is the only part that's just tough at the end of the mocking part. Everything after that, there's really nothing new to it than any other react framework or anything else, it's clearly the same thing.

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