Building Data-Driven Web Apps with Flask and SQLAlchemy Transcripts
Chapter: Testing web apps
Lecture: Avoiding the database call on register

Login or purchase this course to watch this video and the rest of the course contents.
0:00 All right, so there's a problem trying to write this test and it's getting hard. So, we try to run their test and the problem is
0:08 way down here we're trying to create a database session. Why are we trying to create a database session?
0:12 Well, over here we're trying to find the user by email. Why are we doing that? Because the view model wants to make sure
0:19 that you're not already registering as a user that already exists.
0:24 But what are we going to do here? Do we have to just enable the database for our test? No, hopefully we don't. What we can do is
0:31 we can actually go to this method here and we can replace it with another one. There's a bunch of options for this
0:37 but there's a really slick way when we're doing a unit test. Let's go over here and say import unittest. This is the built-in one
0:45 we're not actually using its main features but we're going to use this mock feature here. What mocking does is it says
0:52 I would like to replace a function's behavior with another function that I'm writing. or something along those lines.
0:59 So, what we can do down here is we can say with. Actually, let's set up the target. It's going to be, well it's going to be that function
1:08 that we tried to call over here. It's going to be, where is this? So we just got to type that out.
1:19 or we might be able to find it in our errors down here. If we scrub that will be a little bit of a help
1:36 but anyway we can type it out here. And what we do is we say, with unittest.mock.patch and we're going to replace this function
1:46 and we say the return value is going to be none. And then within that context manager when I call this function. So only will we change the behavior
2:01 of find user by email right here soon this context manager is with block it goes back to talking to the database.
2:08 So this means we don't permanently change it maybe alter the behavior of other task writes only isolated right here which is perfect.
2:17 Let's try this now. This test should work unless I've messed that up. Tada! Look at that. It works when the user is there.
2:26 Now what if we told it to return found, right. Some other user obviously, it's the wrong type
2:32 but it will still crash and say something to the effect of a user with that email address already exists.
2:38 See how cool it is. We just control what the dependencies are trying to do from the outside. We could do this if we're trying to talk to an API
2:47 like Stripe for charging a credit card we could do this for other APIs. All the stuff that we were trying to call
2:52 as long as we build our code up in a decent way we should be able to get in here change just a function or two and make it work. So this is great.
3:02 We're able to run our tests in complete isolation, right. Our tests are passing and the meaningful one here is working.
3:09 What we're doing is we're creating a fake test context so the view model thinks the request is happening
3:16 within Flask and then when it does its operations we're mocking out one of its tendencies the database to control how it behaves.
3:24 Now we have a nice test in isolation.

Talk Python's Mastodon Michael Kennedy's Mastodon