Building data-driven web apps with Flask and SQLAlchemy Transcripts
Chapter: Testing web apps
Lecture: Organizing your tests

Login or purchase this course to watch this video and the rest of the course contents.
0:00 By now, you know that I'm a little bit obsessive
0:03 about organizing my code.
0:05 I really, really don't like having everything
0:08 just jammed into one file, or thrown
0:11 a bunch of files thrown into one directory.
0:13 It really helps take the mental load
0:15 off of where do I find that thing
0:17 if you have a nice organizational structure.
0:19 So when we're testing our code
0:21 we also want to apply something like that.
0:24 We want to have some organization that tells us right
0:27 where to go to look to test a particular thing.
0:30 Now, you can organize your code and your test
0:32 however you want, but please think about it.
0:34 And I'll show you what I use for my test.
0:37 If we look over here at the views
0:39 we already have them grouped
0:40 by the type of view that they are.
0:43 All the stuff to do with the account is
0:44 in the account view file, the CMS page stuff is in CMS
0:48 package stuff is in packages, and so on.
0:50 So I'm going to group my tests in exactly the same way
0:53 and it's also the way we're grouping our templates.
0:55 So it makes a lot of sense to just keep going with that.
0:58 So here, we're going to have an account test file
1:01 in a test folder, and it's going to have
1:03 all the tests that have to do with accounts.
1:06 So it's the register, the login, the view models
1:10 as well as the high-order tests like the integration test.
1:14 Have one for home view, we'll have one for packages.
1:18 So we haven't written any for CMS, we probably should.
1:20 In my little example here, we don't have that yet.
1:23 So you can see, we'll do this grouping here like that.
1:27 Now, another thing that's super, super helpful is
1:29 if we have a site map, that is
1:31 an XML file, that's a standard on the web
1:33 that talks about all the various links on our site.
1:37 It's originally intended to help search engines
1:39 like Google and Bing find all the content in your site.
1:42 Make sure that, even if you don't link to it somewhere
1:44 if you want it to show up in a search engine
1:46 it'll show up there, so it basically has a link
1:48 to every single, at least public, URL on your site.
1:52 And what we can do is we can actually use this site map
1:56 go make a request to it, a dummy request to it
1:58 to get the XML document back
2:01 and then just go and request every single page.
2:04 That actually covers a huge, huge swath
2:07 of what you need to test.
2:08 Because what often happens is
2:10 it's not like there's something super minor
2:12 that's wrong on your site.
2:13 If something goes wrong, a lot of times
2:15 it just goes really wrong and crashes the page and is a 500.
2:19 So like, think about the packages details page.
2:22 If something's wrong with that query
2:23 and what we get back is none instead of a package
2:26 it's not likely just going to work.
2:29 It's either going to give you a 404, which is an error
2:31 or, if you try to render the template
2:33 you're going to get a 500 because it's going to crash
2:35 with a error, attribute error.
2:37 None does not have whatever thing you're trying to get at
2:40 like the name or the version or whatever.
2:42 So actually requesting the pages, you'll find
2:44 a lot of times, if something goes wrong
2:45 you'll find the page will actually crash.
2:47 And the site map test is going to uncover those types
2:51 of errors, basically with no effort on our part.
2:54 It's really, really beautiful.
2:55 So here's how we're going to organize our test for our project.