• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL

Chapter 42. Writing Functional Tests > The Browser Test Case

The Browser Test Case

Each custom functional test case class provides some valuable methods that help you write the tests in a fast and efficient manner. The BrowserTestCase class provides the following methods:

  • getRootFolder() This method returns the root folder of the database. This method is available in every functional test case class.

  • commit() This method commits a transaction to the database. This is particularly useful when you add objects to the database before publishing a request. If the transaction is not committed after the setup of the object, the object will not be available when calling the publishing process. This method is available in every functional test case class.

  • abort() This method aborts a transaction of the database. It is available in every functional test case class.

  • makeRequest(path=", basic=None, form=None, env=, outstream=None) This method creates a new BrowserRequest instance that can be used for publishing a request with the Zope publisher. Here are its arguments:

    • path This is the absolute path of the URL (that is, the URL minus the protocol, server, and port) of the object that is being accessed.

    • basic This provides the authentication information, in the format login:password. When Zope 3 is brought up for functional testing, a user with the login mgr and the password mgrpw is automatically created, and it is assigned the role zope.Manager. Therefore, usually you use mgr:mgrpw as the basic argument.

    • form This argument is a dictionary that contains all fields that would be provided by an HTML form. Note that you should have already converted the data to the native Python format; you need to be sure to only use Unicode for strings.

    • env This variable is also a dictionary, and in it, you can specify further environment variables, such as HTTP headers. For example, the header X-Header: value would be an entry in the env dictionary of the form 'HTTP_X_HEADER': value.

    • outstream Optionally, you can define the stream to which the outputted HTML is sent. If you do not specify one, one is created for you.

    You would often not use this method directly because it does not actually publish the request. Instead, you use the publish() method, described next.

  • publish(self, path, basic=None, form=None, env=, handle_errors=False) This method creates a request as described for the makeRequest() method that is then published with a fully running Zope 3 instance and then returns a regular browser response object that is enhanced by a couple methods:

    • getOutput() This method returns all the text that was pushed to the out stream.

    • getBody() This method only returns all the HTML of the response. It therefore excludes HTTP headers.

    • getPath() This method returns the path that was passed to the request.

    path, basic, form, and env have the same semantics as the arguments to makeRequest() that have the same names. If handle_errors is False, any exceptions that occur are not caught. If handle_errors is True, the default view of an exception is used, and a formatted HTML page is returned. As you can imagine, having handle_errors set to False is often more useful for testing.

  • checkForBrokenLinks(body, path, basic=None) Given an output body and a published path, this method checks whether the contained HTML contains any links and checks that those links are not broken. Because the availability of pages and therefore links depends on the permissions of the user, you might want to specify a login/password pair in the basic argument. For example, if you have published a request as a manager, it will be very likely that the returned HTML contains links that require the manager role.



Not a subscriber?

Start A Free Trial

  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint