Test the basic rendering of all views

[enewe101]

_The following is a good issue for new developers. It will introduce you to the testing framework, the urlresolver, and python inheritance.

Intro

The Selenium WebDriver software allows us to run tests of the site through a Firefox browser, by simulating user interactions. This means that we can run tests which initiate a request from a browser, and then verify that the content sent back to the browser is correct, i.e. it allows us to run "end-to-end" tests.

This issue is to create a suite of tests that verify the rendering of all of the views. The purpose with these tests is not to verify details of form interaction or the consistency of business logic, but rather, simply to verify that each page displays as expected.

Task

A dedicated test class called RenderTest should be created inside ~/test.py for this purpose. RenderTest should extend SeleniumTestCase.

Write a method in RenderTest called validate_render(). This method should accept one argument consisting of a list called render_specs, which contains a series of dicts, each called a render_spec. Each render_spec should contain the keys element_id, and content. The method validate_render() should go through the list of render_specs and use Selenium to verify that each element specified in the element_id exists, and contains content. It should be allowed that content can be None, in which case, render_test() will only verify that the element element_id exists, and won't check its content. If content is the empty string, that should be tested as an assertion that the element content actually is the empty string.

Next, make methods to test every view listed in urls.py. There should be one test method per view. These methods should be named like this: test_<view-name>. You can tell what the <view-name> of a view is by looking at the third argument passed into url() in the urls list. Note that, inside an instance of TestCase, methods whose name starts with test_ will get discovered and executes as a tests when the command python manage.py test is issued in~/src.

Each test method should do this:

1. load the desired page,
2. define a set of render_specs, and pass them to render_test, to validate crucial contents have rendered
3. perform any other desirable validation that can't be done as a simple find-element-by-id-and-verify-it's-contents. For example, we should include on the main page a test that the main banner image actually loaded, and on user-content pages that display users's avatars, we should check that the avatars are actually displayed.

It's not necessary to test a views handling of POST requests (i.e. you do not need to validate form submission -- we have other tests for that).

Tip

Some views will require that the user logs in first. Since it will be common to need to login, create a method called login() which fills out the login form and submits it. You can login using the testing user regularuser whose password is regularuser. Since logging in will potentially be needed by any test using Selenium, put this method at a higher point in the inheretance structure, as a method for SeleniumTestCase.

Tip

While writing your tests, you'll find it convinient to be able to run only that test, rather than the whole suite. You can do that by issuing the command python manage.py test digidemo.test.<TestCaseName>.<test_method_name>

[enewe101]

Ideally, these tests should be written in such a way that they would run on a local machine, issuing http requests to a test deployment server over the Internet. This will give us a suite of tests that truly tests the full stack, including the network dependency.