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?

1. If John goes to the homepage, he wants that our homepage loads successfully. This means its HTTP response code should be 200

2. 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).

3. 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.

4. And finally he still wants to see the "Messages With 300 Chars" on the page.

Wikipedia says

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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.

from functional_tests import FunctionalTest, ROOT

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)

    def test_can_view_home_page(self):
        # Let's check if the website was loaded ok => response code == 200
        response_code = self.get_response_code(self.url)
        self.assertEqual(response_code, 200)

    def test_has_right_title(self):        
        # First he looks at the topbar and sees 'Microposts On Steroids'
        title = self.browser.find_element_by_tag_name('title')
        self.assertEqual('Microposts On Steroids', title.text)

    def test_has_right_heading(self):        
        # He's looking for the Heading "Messages With 300 Chars"
        body = self.browser.find_element_by_tag_name('body')
        self.assertIn('Messages With 300 Chars', body.text)

What does this code do?

1. 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 to http://localhost:8001/tukker/ and our webdriver (Firefox) loads this URL before each test.

2. The test_can_view_home_page method checks if the page is loaded without unexpected errors. We check if the web server response with 200, which means everything worked fine.

3. test_has_right_title looks out for a title element in the webpage and does make sure it carries the right text.

4. 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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.

...
use "kill -SIGTERM 5405" to shutdown the web2py server
F
======================================================================
FAIL: test_can_view_home_page (test_static_pages.TestHomePage)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/macco/Dropbox/web2pytutorial/web2py/applications/tukker/fts/test_static_pages.py", line 17, in test_can_view_home_page
    self.assertEqual('Microposts On Steroids', title.text)
AssertionError: 'Microposts On Steroids' != u'Tukker'

----------------------------------------------------------------------
Ran 1 test in 11.043s

FAILED (failures=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.