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,[1] 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:
200 OK
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
test_static_pages.py
:
1. | $ gedit fts/test_static_pages.py |
in gedit change the file to:
1. | from functional_tests import FunctionalTest, ROOT |
What does this code do?
The
setUp
method, 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 tohttp://localhost:8001/tukker/
and our webdriver (Firefox) loads this URL before each test.The
test_can_view_home_page
method checks if the page is loaded without unexpected errors. We check if the web server response with200
, which means everything worked fine.test_has_right_title
looks out for atitle
element in the webpage and does make sure it carries the right text.test_has_right_heading
is adopted from our first test in chapter 4.
If you now start our tests, you should see some simular output:
1. | ... |
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.
This method will not work because "browser" is a local variable within FunctionalTest class, so you need to declare it outside at class level. class TestHomePage (FunctionalTest): def setUp(self): # John opens his browser and goes to the home-page of the tukker app self.url = ROOT + '/tukker/' get_browser=self.browser.get(self.url) <---- error "browser" attribute not found #solution - go to FunctionalTest and add the browser attribute FunctionalTets(unittest.Testcase): # add these two variables so they can be seen in derived browser = None web2py = None