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

The "Q&A" 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 answers questions about mocking the OpenAI API and other testing strategies specific to this application.


Transcript from the "Q&A" Lesson

>> Regarding testing, how would you mock the open API requests?
>> Same thing. It would be a lot more code, but it's the same, it's the same. Well, I guess, I mean, I guess there's a lot of ways you can do it actually, let me show you. So, Vitest has so many ways to do mocking, there's not just one way, I just mocked out the whole module.

But because the way Ling chain does its imports, I guess that could be kinda weird. So you could just mock it out on a per function basis. Let me see if they have an example of that. Not that. Here we go. So you can do like a spy.mockimplementonce, to literally look at specific functions.

You can do V dot function to mock the implementation like a specific function like this. So there's a lot of ways you could do it. I mean, you probably could just mock out the whole module to like we did in a test and then what you could do is just do this part right here, you see where I'm mocking out the entire module.

But these are the only methods that I'm stubbing. So, for the open AI one, if you go to AI, the place in which we're calling Open AI would be So if you look at the call that comes from model, model comes from Open AI, open AI comes from this path.

So you could just mock this whole path out. And then stub this open API to be a class that returns something with a call method on it that does nothing. So like I said, it's just a lot more code but that's how you would do it.
>> And a little bit more generally speaking with testing, what else in this app would you want to test?

What would I want to test?
>> So I wouldn't be testing any of the content on the page because I'd probably be using a CMS and the data would be dynamic anyway. So I wouldn't be testing that. I would probably test to see that certain elements are on the page though.

Because certain elements means certain components were loaded up. So I would be testing that, for instance, I might test that loading animation spinner for a auto save is there and not take it away. I will test anything that has a conditional, which is a branch. So anything with a branch I wanna test to make sure that we handle that conditional.

So I would try to throw different things that inputs to see those conditionals that can be something like a conditional and a JSX. That could be something like this where the button is changing. So I was like, okay, I'm gonna make a new mock, make user ID there for one, test it to make sure it's journal, and then mock it out to where user ID is not there and then test to see if that says new user, right?

So I'll test each conditional like that. Anywhere there's logic. I'm not so concerned about just pure rendering, I'm only concerned if there's logic. So like pretty much anywhere there's like interpolating, I will be like looking in here. So I'll test that. I'll test like if there's like a map in here.

Anywhere there's interpolation, I'm gonna test, everything else I'm not testing for. Really not worth it. You don't wanna go out and just like, alright, a two string equals this two string and like see these two strings? I mean, I guess that's what snapshot testing is. But yeah, I would do that.

And then obviously the easy one is just all these utilities. These have nothing to do it react and just plain old JavaScript functions that you can test, no problem. So all these should be tested. And then I would probably test the API because these are also very easy to test.

They're just functions. You can stub out everything that's passed to them. So this is literally just a function. You can stub out any one of these. It's pure node, even a request object that came in here. You could just pass it on yourself and stub it out. So I would test that, you can spy on these next responses to see what information they got back to make sure it's correct.

Yeah that's that's probably everything I would test.
>> I will piggyback on that with we just released a couple weeks ago, an enterprise UI development course. The context of the course is maintaining a very large code base, but it's covers everything testing related to that from component to integration to mocking and spying and so if you're interested in just testing in general that's another great new course that we that we released.

>> Yep, cool any other questions?
>> Regarding responsive design you didn't use the tailwind classes but can you speak briefly to, how you would approach responsive design with Halo, is it easier to use those classes from the beginning or kind of stuff everything out like you have now and then add the classes in after?

>> Yeah, I think if you're gonna do responsive design, you should make it mobile first. So all the classes you use are meant to be on mobile and then you add classes going up. I think if you add classes going down it's so much harder to do that in my opinion.

>> So if I were to make this responsive from day one, like for instance this page, like I think some people like, okay, I'm gonna go in here but like for a small screen, which which is how you do this until when, I'm gonna do this thing. I wouldn't do it that way.

All of this CSS, all these classes here would be for a phone by default. And then, I'm like, okay, now for a desktop where it's large, then I would add like a different width here or something. I would change it on the way up, so that's how I would do it if I was gonna do it would tell when much easier going up and down Yep.

>> I've more ore of a general question, when you're coming up with a project like this, do you kinda have a process, do you come up with the idea first and then find the technology are you poking around in the technology and then the idea developed?
>> Yeah, that's a good question.

So I mean, with these technologies, so I usually try not to teach anything that I'm not constantly using and super passionate about. So it's always just on my mind about, the thing that I'm teaching. So with next.js and anything AI related, that's just what I've just been using forever.

And as far as like the idea, it's I don't really have a process. I think it's more like what sounds, what do I think people would like making? What sounds cool? And the only thing that I try to scope it off of is like, is it teachable? Because there's like really a lot of things that I can just sit up here and just make, but it wouldn't be a good experience for anyone just to watch me just struggle to Google looking up things.

So I have to make sure that it's teachable and it's building on something. So that's the only filter that I have. But yeah, really? I do have a, I guess I think about if I really thought about it, I there's things I tried to stay away from. Which are like, I try to stay away from apps that aren't impressive unless you have a bunch of data.

Like for instance, if I was like, let's rebuild Twitter, that sounds cool, but unless you have a bunch of tweets on the page, it looks, it's pretty bad. Or unless it's like, hey, we're all using the same server and we can see each other's tweets, it's really not that fun.

It's social by nature, so if we can't demonstrate that social aspect, it's really not that impressive. So I try to stay away from multiplayer social experiences because they're not that impressive unless you're doing it together. So it mostly lands on like productivity type things because most productivity apps are like solo where you can just do your own thing.

Maybe it's better with people, but you could totally do it. You can work on Notion by yourself. So it's usually that. And then, I do also tend to make sure that the app, as far as like the features that it has, are very simple. And then I just expand on top of that because I think it's those things in between that you would need to know as like an engineer having a job.

I think it's really cool to like, I built this AI feature. But you know what's better? Is that you understand authentication and you understand how these things in between these features work because every single app are gonna have these features in between. They're gonna have the table stakes, right?

It doesn't matter what app you make, your own routing, you're gonna be testing, you're gonna need components, you're gonna need data fetching, you're gonna be caching. So I like to focus on those things and just sprinkle like features in that aren't really unique or that are unique to the app, but you probably won't see in any other app 'cause it's just too unique for this.

So that's just kinda my thought process.

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