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