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