In the last chapter we began writing tests for our tukker app, we checked if our homepage contained the text "Messages With 300 Chars" in its body. This was ok for a demonstration purpose, but for our tukker app we need more sophisticated tests.
What do we want to test? What does John want to test?
- If John goes to the homepage, he wants that our homepage loads successfully. This means its HTTP response code should be 200
200 stands for "success". (You can check the response code with Curl, e.g., go to the command line and type in
curl --head www.[example].com).
John want's to see a title in the topbar of his browser and it should say: "Micropost On Steroids". This means in the HTML structure should be a
title-tag. We will learn more about that in this chapter.
And finally he still wants to see the "Messages With 300 Chars" on the page.
HTTP status codes
The following is a list of HyperText Transfer Protocol (HTTP) response status codes. This includes codes from IETF internet standards as well as unstandardised RFCs, other specifications and some additional commonly used codes. The first digit of the status code specifies one of five classes of response; the bare minimum for an HTTP client is that it recognises these five classes. Microsoft IIS may use additional decimal sub-codes to provide more specific information, but these are not listed here. The phrases used are the standard examples, but any human-readable alternative can be provided. Unless otherwise stated, the status code is part of the HTTP/1.1 standard. Examples are:
Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request the response will contain an entity describing or containing the result of the action.
400 Bad Request
The request cannot be fulfilled due to bad syntax.
404 Not Found
The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.
This means for us we have to change the tests in
$ gedit fts/test_static_pages.py
in gedit change the file to:
from functional_tests import FunctionalTest, ROOT
What does this code do?
setUpmethod, is a special method or function (we will learn what the difference is in the chapter 5), that is executed before every test. In our case it ensures that the URL is set to
http://localhost:8001/tukker/and our webdriver (Firefox) loads this URL before each test.
test_can_view_home_pagemethod checks if the page is loaded without unexpected errors. We check if the web server response with
200, which means everything worked fine.
test_has_right_titlelooks out for a
titleelement in the webpage and does make sure it carries the right text.
test_has_right_headingis adopted from our first test in chapter 4.
If you now start our tests, you should see some simular output:
We were lucky, our first test assertion, for the right HTTP response
code, passed thanks to web2py (the index-controller in the
default.py gets created by default). Our second assertion didn't pass. We will change this now in the next section. Remember, this is the way you should go: First fail the tests (to see the tests are working) and then fix it.