Building Data-Driven Web Apps with Pyramid and SQLAlchemy Transcripts
Chapter: Testing web apps
Lecture: Concept: view method tests

Login or purchase this course to watch this video and the rest of the course contents.
0:00 Let's look at testing these views again. We're just passing in the requests The view method probably works with the view model but it doesn't have to.
0:08 We also saw this view method probably talks to the database and that can become a challenge. So let's see how that works.
0:15 Well, we're going to say test the home page. So we're going to do our Arrange which means we import the action method called index
0:23 in our HomeController we had a function called index that maps to /. In order to call it, which is what we want to do we have to pass a request.
0:32 So as we've seen before we create the dummy request and we're going to just call index passing the request
0:37 and getting the model that returned back, back. And in our world there's supposed to be a packages list on the homepage
0:46 so we can show the latest releases. So we're going to grab that out of the dictionary and then assert that there's at least one package in it.
0:54 We're also asserting that the key exists 'cause the square brackets would be a key error but we could get it the other way, right?
0:59 So there's no, There's not the absence of packages. They are being passed, right. This might not be the best test for the homepage
1:06 but it demonstrates the kinds of things you would look for. Well this is cute right. Where'd those packages come from though?
1:12 They came from the database didn't they? So chances are this won't even work and if it did work it's probably talking to the database
1:20 by some miraculous way and you want to not let it do that. You want to control where it gets it's data from so let's look at a more realistic view.
1:29 Now, for the more realistic view we need more room. Okay, but let's suppose we're trying to get ahold of the package details
1:37 and we want to do that by requesting a certain package but not actually going to the database. Again we're going to Arrange and get our project method
1:47 our project view from the PackageController. And we're also going to work with package 'cause we need to create some test data.
1:54 We're going to get our fake request. We're going to create some fake package data and we put that into a function
1:59 and it could be really elaborate, we don't need to worry about the details we just allocate a new package objects
2:03 give it a bunch of releases and properties and so on right there. Our request has a package name which is SQLAlchemy.
2:09 Now apparently we use Get so it's like query string but whatever, matchdict, query string whatever your app does we say
2:15 request, here's what they're asking for, SQLAlchemy. And then in order to intercept a database behavior we're going to define a with block for
2:25 and also one, in this case imagine we're calling it a function, releases_for_package
2:32 rather than using the SQLAlchemy relationship. So we're going to intercept both of these and then we're going to finally act.
2:40 Just call the function with the fake request and the fake underlying database methods. Boom, out comes your info
2:47 and then finally we can assert around that. Get us thing back, we'll call it web package to make it not ambiguous.
2:54 By pulling that out of the model return and we can assert things like its id is SQLAlchemy and it has two releases which are
2:59 create fake package data, give it. Things like that. This let's us create isolated tests by both passing in required infrastructure
3:10 and replacing it behind the scenes with Patch.

Talk Python's Mastodon Michael Kennedy's Mastodon