{"id":381,"date":"2013-01-16T22:00:43","date_gmt":"2013-01-16T21:00:43","guid":{"rendered":"http:\/\/blog.gocept.com\/?p=381"},"modified":"2013-04-02T23:16:43","modified_gmt":"2013-04-02T21:16:43","slug":"news-from-the-toolbox-gocept-selenium-and-our-plans-for-its-future","status":"publish","type":"post","link":"https:\/\/blog.gocept.com\/2013\/01\/16\/news-from-the-toolbox-gocept-selenium-and-our-plans-for-its-future\/","title":{"rendered":"News from the toolbox: gocept.selenium and our plans for its future"},"content":{"rendered":"

For a couple of years, we at gocept have been developing a Python library, gocept.selenium<\/a>, whose goal it is to integrate testing web sites in real browsers with the Python unittest framework. There exist a number of approaches to doing this; when first starting real-browser tests, we opted for using selenium<\/a>. Back then, it had not been integrated with webdriver yet (more on webdriver below).<\/p>\n

There turned out to be multiple aspects to selenium integration: setting up the web server under test, starting a browser to run selenium and pointing it at the server, but also designing a wrapper around the selenium testing API to bring it in line with unittest’s way of defining specialised assertions.<\/p>\n

We came up with the gocept.selenium package which includes both a selenese module defining such an API wrapper and a bunch of modules for integration with those web-server frameworks that we happen to use in our work, among them generic WSGI<\/a> and a number of Zope<\/a>-related servers. The integration mechanism is implemented in terms of test layers, so all of this requires the Zope test runner<\/a> to be used. We released a 1.0 version of gocept.selenium in November 2012, marking the selenese API as stable.<\/p>\n

The description of the package given so far already indicates two aspects that need yet to be addressed: Firstly, the selenium project is based on webdriver nowadays, with the old selenium implementation being kept for backwards compatibility at the moment. Secondly, collecting all those server integration modules in the same package that implements the actual selenium integration makes for rather complex (albeit optional) package dependencies and poses a maintainability problem.<\/p>\n

We have dealt with the latter in December 2012, extracting all those integration modules from gocept.selenium into a new package, gocept.httpserverlayer<\/a>. From the package’s documentation:
\n\u00bbThis package provides an HTTP server for testing your application with normal HTTP clients (e.g. a real browser). This is done using test layers, which are a feature of zope.testrunner. gocept.httpserverlayer uses plone.testing<\/a> for the test layer implementation, and exposes the following resources (accessible in your test case as self.layer[RESOURCE_NAME]):<\/p>\n