Django: Getting Started Transcripts
Chapter: Your First Django App
Lecture: Writing a 'say hello' view test
0:00 Different developers organized this next bit differently. I mentioned you can put tests in your project or in your app.
0:09 I tend to keep all my tests together in the project unless I'm writing an app that will be shipped separately.
0:15 I'm sure if you dig around on the net you'll find someone who thinks I'm doing this wrong.
0:20 Wrong or not, I'm going to create a director here for my unit tests at the project level. Now inside of that I'll create a file for the tests.
0:38 Like Python unit tests, Django expects these files to begin with the word test. This is how the test runner finds them.
0:46 Your test case will live in a class that inherits from test case. Good naming. So the first thing I have to do is import it.
1:01 Test case is an overloaded version of Python's unit tests class. I've defined a test class named primer test case.
1:10 Inside the test case I'll define a method starting with the word test. This is the actual test that will be run.
1:21 Like with the name of the file, Django expects test cases to be methods starting with the word test.
1:27 This might seem redundant but it allows you to write helper methods in the class that aren't test cases simply by naming them something else.
1:35 The first thing I'm going to do in this test is to visit our URL Django's test case object comes with an attribute named client.
1:49 This is a mechanism that can be used to visit URLs. Here, I've used the clients get method to visit our
1:57 say hello URL, know that this looks like a web scraper but it isn't the
2:02 URLs that will work in this mechanism are only those defined in Django maping's. Django doesn't actually run a server when you run the tests.
2:11 When lines six runs whatever happens when you visit the URL the result gets stored in an object named response.
2:19 I'm going to run two checks on the response. The first is the response code of the URL
2:28 visited http has a series of codes that indicate success or failure of any particular URL visited.
2:36 You're probably familiar with the infamous 404 code which means there's no content for the URL you put in.
2:43 You may also have come across the 500 which is a server error. That one typically means the software generating the web page crashed.
2:52 You might not know code 200. That's the code for success. You're getting 200's all the time. But because the response was successful,
2:59 your browser is rendering the result so you don't see the code directly. The get method of the client returns a response object
3:07 that has a parameter called status code. That is where it stores the http response code,
3:13 the test case class that the primer test case inherits from overloads Pythons unit tests and includes several methods for comparing values.
3:23 Here I've used the assert equal method. If the response code is 200, then this code will continue to execute.
3:30 If the response was something other than 200, this code will exit and report an error.
3:40 The response object returned from the get also contains everything that came back from the view
3:45 It stores this in an attribute called content because of the wonderful world of unicode, that content is actually stored as binary.
3:54 So before doing anything with it, I'm converting it to a string. In this case I'm making sure that the content contains the word Hello.
4:03 You'll recall that the view said hello world. This time instead of using assert equal, I've used assert in, if hello is found inside the content then
4:13 the test passes. You can also get at http headers and all sorts of information in the response object. For now though, this test is good enough.
4:23 Let's go back to the terminal and run it. I'm back in my terminal in the Alexandria directory.
4:28 To run the test, I just wrote I use the test subcommand of the managed pyscript. Note, I'm on a Mac which is eunuchs underneath.
4:37 So I'm using the dot forward slash shortcut for running the script. If you're on Windows, you'll have to type out the whole thing Python manage.py test
4:47 The subcommand creates a special database just for the testing, checks that your configuration is sane, and then runs your tests.
4:54 In this case only a single test is found, it's executed rather quickly and passes. Once all that is done the special test database is cleaned up.
5:06 And that's it, you've successfully run your first Django unit test.