Tools for unit testing¶
- class reahl.dev.fixtures.ReahlSystemSessionFixture¶
Fixturewhich sets up all the basics any Reahl system needs to run.
Upon set up, it creates a new empty database with the correct database schema for the project and sets up any persistent classes for use with that schema. It also connects to the database. Upon tear down, the Fixture disconnects from the database.
To be able to do all that, it needs to provide a basic
ExecutionContextwith the appropriate configuration, which it reads from the ‘etc’ directory relative to the current directory.
You should not use this fixture directly in tests because changes to, eg. the
ExecutionContextit provides will persist between different tests. The idea is for ReahlSystemSessionFixture to be used by other
Fixtures that are not session scoped, but that uses this one where necessary. See for example
Configurationof the system.
This is read from disk from the ‘etc’ directory present in the current working directory where tests are run.
- class reahl.dev.fixtures.ReahlSystemFixture¶
Fixturefor direct use in test which sets up all the basics any Reahl system needs to run.
ReahlSystemFixture does its work by using a
ReahlSystemSessionFixturebehind the scenes. ReahlSystemFixture provides copies of most of the session-scoped stuff in the
ReahlSystemSessionFixture. This allows you to “inherit” the configuration set up for the session by default, but also allows you to change the configuration and ExecutionContext for a particular test, safe in the knowledge that such changes will be torn down after each test function ran.
Managing a SqlAlchemy database¶
- class reahl.sqlalchemysupport_dev.fixtures.SqlAlchemyFixture¶
SqlAlchemyFixture ensures that a transaction is started before each test run, and rolled back after each test so as to leave the database unchanged between tests. It also contains a handy method
persistent_test_classes()that can be used to add persistent classes to your database schema just for purposes of the current test.
A context manager that creates the tables needed for the entities passed to it, and which sets the necessary SqlAlchemy wiring up for thos entities to work. The tables are destroyed again after the context is exited.
This is useful for having persistent classes that may even need their own tables in the database but which should stay part of test code only, and are thus not listed in the <persisted> section of any egg.
Web development fixtures¶
- class reahl.web_dev.fixtures.WebServerFixture¶
A Fixture to be used as session fixture. It sets up a running, configured web server before any test runs, and more than one flavour of a Selenium 2.x WebDriver. WebServerFixture also stops all the necessary servers upon tear down.
The web server started runs in the same thread as your tests, making debugging easier.
A WebDriver instance set up to work with the running reahl_server, via Firefox.
A WebDriver instance set up to work with the running reahl_server, via Chrome. Note that this expects a Chrome binary to be present at /usr/lib/chromium-browser/chromium-browser
The default WebDriver instance (Chrome, by default).
- class reahl.web_dev.fixtures.WebFixture¶
A function-scoped Fixture for use when testing a website via selenium or to test things as if you are inside the server.
For example, it supplies a View for when you want to instantiate a Widget.
- property context¶
- property config¶
- new_request(path=None, url_scheme=None)¶
- log_in(browser=None, session=None, system_account=None, stay_logged_in=False)¶
Logs the user into the current webapp without having to navigate to a login page.
DriverBrowserinstance for controlling the browser.
- property chrome_driver¶
A selenium WebDriver instance for Chromium.
- property firefox_driver¶
A selenium WebDriver instance for Firefox.
- property web_driver¶
The default selenium WebDriver instance.
- property reahl_server¶
The running Reahl webserver.
To use it, you will have to call
set_app()to specify the WSGI application to serve.
- new_wsgi_app(site_root=None, enable_js=False, config=None, child_factory=None)¶
UserInterfacewith a single View.
site_root – an optional supplied
UserInterfacefor the webapp
enable_js – If True, JS files will be served. The default is False, to save time.
config – A configuration to use.
child_factory – A Widget to include in the single-view site (only applicable if no site_root) is given.
- property current_location¶
Urlas displayed in the browser location bar.
UrlBoundViewto use when constructing
Widgets for testing.
General web development tools¶
- class reahl.webdev.webserver.ReahlWebServer(config)¶
A web server for testing purposes. This web server runs both an HTTP and HTTPS server. It can be configured to handle requests in the same thread as the test itself, but it can also be run in a separate thread. The ReahlWebServer requires a certificate for use with HTTPS upon startup. A self signed certificate has been provided as part of the distribution for convenience.
config – The
reahl.component.config.Configurationinstance to use as config for this process.
- classmethod from_config_directory(directory)¶
Creates a new ReahlWebServer given a port and standard configuration directory for an application.
directory – The directory from which configuration will be read.
- ..versionchanged:: 5.1
Removed port keyword argument, port and encrypted port will be set from the config found in the directory argument.
- ..versionchanged:: 5.1
Renamed from camel case name.
Changes the currently served application to new_wsgi_app.
- start(in_separate_thread=True, connect=False)¶
Starts the webserver and web application.
in_separate_thread – If False, the server handles requests in the same thread as your tests.
connect – If True, also connects to the database.
Stops the webserver and web application from running.
Call this method once to have the server handle all waiting requests in the calling thread.
Installs this server’s request handler into the given web_driver. This enables the server to serve requests from the web_driver in the current thread.
Returns a context manager. Within the context of this context manager, the webserver is temporarily run in a separate thread. After the context managed by this context manager is exited, the server reverts to handling requests in the current (test) thread.
wait_till_done_serving – If True, wait for the server to finish its background job before exiting the context block.