plone.app.testing 4.2.7

Compatibility

plone.app.testing 4.x works with Plone 4 and Zope 2.12. It may work with newer versions. It will not work with earlier versions. Use plone.app.testing 3.x for Plone 3 and Zope 2.10.

Plone site fixture

This layer sets up the Plone site fixture on top of the z2.STARTUP fixture.

You should not use this layer directly, as it does not provide any test lifecycle or transaction management. Instead, you should use a layer created with either the IntegrationTesting or FunctionalTesting classes, as outlined below.

Integration and functional testing test lifecycles

plone.app.testing comes with two layer classes, IntegrationTesting and FunctionalTesting, which derive from the corresponding layer classes in plone.testing.z2.

These classes set up the app, request and portal resources, and reset the fixture (including various global caches) between each test run.

As with the classes in plone.testing, the IntegrationTesting class will create a new transaction for each test and roll it back on test tear- down, which is efficient for integration testing, whilst FunctionalTesting will create a stacked DemoStorage for each test and pop it on test tear- down, making it possible to exercise code that performs an explicit commit (e.g. via tests that use zope.testbrowser).

When creating a custom fixture, the usual pattern is to create a new layer class that has PLONE_FIXTURE as its default base, instantiating that as a separate “fixture” layer. This layer is not to be used in tests directly, since it won’t have test/transaction lifecycle management, but represents a shared fixture, potentially for both functional and integration testing. It is also the point of extension for other layers that follow the same pattern.

Once this fixture has been defined, “end-user” layers can be defined using the IntegrationTesting and FunctionalTesting classes. For example:

from plone.testing import Layer
from plone.app.testing import PLONE_FIXTURE
from plone.app.testing import IntegrationTesting, FunctionalTesting

class MyFixture(Layer):
    defaultBases = (PLONE_FIXTURE,)

    ...

MY_FIXTURE = MyFixture()

MY_INTEGRATION_TESTING = IntegrationTesting(bases=(MY_FIXTURE,), name="MyFixture:Integration")
MY_FUNCTIONAL_TESTING = FunctionalTesting(bases=(MY_FIXTURE,), name="MyFixture:Functional")

See the PloneSandboxLayer layer below for a more comprehensive example.

Plone integration testing

This layer can be used for integration testing against the basic PLONE_FIXTURE layer.

You can use this directly in your tests if you do not need to set up any other shared fixture.

However, you would normally not extend this layer - see above.

Plone functional testing

This layer can be used for functional testing against the basic PLONE_FIXTURE layer, for example using zope.testbrowser.

You can use this directly in your tests if you do not need to set up any other shared fixture.

Again, you would normally not extend this layer - see above.

Plone ZServer

This is layer is intended for functional testing using a live, running HTTP server, e.g. using Selenium or Windmill.

Again, you would not normally extend this layer. To create a custom layer that has a running ZServer, you can use the same pattern as this one, e.g.:

from plone.testing import Layer
from plone.testing import z2
from plone.app.testing import PLONE_FIXTURE
from plone.app.testing import FunctionalTesting

class MyFixture(Layer):
    defaultBases = (PLONE_FIXTURE,)

    ...

MY_FIXTURE = MyFixture()
MY_ZSERVER = FunctionalTesting(bases=(MY_FIXTURE, z2.ZSERVER_FIXTURE), name='MyFixture:ZServer')

See the description of the z2.ZSERVER layer in plone.testing for further details.

Plone FTP server

This is layer is intended for functional testing using a live FTP server.

It is semantically equivalent to the PLONE_ZSERVER layer.

See the description of the z2.FTP_SERVER layer in plone.testing for further details.

Plone site context manager

ploneSite(db=None, connection=None, environ=None)

Use this context manager to access and make changes to the Plone site during layer setup. In most cases, you will use it without arguments, but if you have special needs, you can tie it to a particular database instance. See the description of the zopeApp() context manager in plone.testing (which this context manager uses internally) for details.

The usual pattern is to call it during setUp() or tearDown() in your own layers:

from plone.testing import Layer
from plone.app.testing import ploneSite

class MyLayer(Layer):

    def setUp(self):

        ...

        with ploneSite() as portal:

            # perform operations on the portal, e.g.
            portal.title = u"New title"

Here, portal is the Plone site root. A transaction is begun before entering the with block, and will be committed upon exiting the block, unless an exception is raised, in which case it will be rolled back.

Inside the block, the local component site is set to the Plone site root, so that local component lookups should work.

Warning: Do not attempt to load ZCML files inside a ploneSite block. Because the local site is set to the Plone site, you may end up accidentally registering components in the local site manager, which can cause pickling errors later.

Note: You should not use this in a test, or in a testSetUp() or testTearDown() method of a layer based on one of the layer in this package. Use the portal resource instead.

Also note: If you are writing a layer setting up a Plone site fixture, you may want to use the PloneSandboxLayer layer base class, and implement the setUpZope(), setUpPloneSite(), tearDownZope() and/or tearDownPloneSite() methods instead. See below.

User management

login(portal, userName)

Simulate login as the given user. This is based on the z2.login() helper in plone.testing, but instead of passing a specific user folder, you pass the portal (e.g. as obtained via the portal layer resource).

For example:

import unittest2 as unittest

from plone.app.testing import PLONE_INTEGRATION_TESTING
from plone.app.testing import TEST_USER_NAME
from plone.app.testing import login

...

class MyTest(unittest.TestCase):

    layer = PLONE_INTEGRATION_TESTING

    def test_something(self):
        portal = self.layer['portal']
        login(portal, TEST_USER_NAME)

        ...

logout()

Simulate logging out, i.e. becoming the anonymous user. This is equivalent to the z2.logout() helper in plone.testing.

For example:

import unittest2 as unittest

from plone.app.testing import PLONE_INTEGRATION_TESTING
from plone.app.testing import logout

...

class MyTest(unittest.TestCase):

    layer = PLONE_INTEGRATION_TESTING

    def test_something(self):
        portal = self.layer['portal']
        logout()

        ...

setRoles(portal, userId, roles)

Set the roles for the given user. roles is a list of roles.

For example:

import unittest2 as unittest

from plone.app.testing import PLONE_INTEGRATION_TESTING
from plone.app.testing import TEST_USER_ID
from plone.app.testing import setRoles

...

class MyTest(unittest.TestCase):

    layer = PLONE_INTEGRATION_TESTING

    def test_something(self):
        portal = self.layer['portal']
        setRoles(portal, TEST_USER_ID, ['Manager'])

Product and profile installation

applyProfile(portal, profileName)

Install a GenericSetup profile (usually an extension profile) by name, using the portal_setup tool. The name is normally made up of a package name and a profile name. Do not use the profile- prefix.

For example:

from plone.testing import Layer

from plone.app.testing import ploneSite
from plone.app.testing import applyProfile

...

class MyLayer(Layer):

    ...

    def setUp(self):

        ...

        with ploneSite() as portal:
            applyProfile(portal, 'my.product:default')

            ...

quickInstallProduct(portal, productName, reinstall=False)

Use this function to install a particular product into the given Plone site, using the portal_quickinstaller tool. If reinstall is False and the product is already installed, nothing will happen; if reinstall is True, the product will be reinstalled. The productName should be a full dotted name, e.g. Products.MyProduct, or my.product.

For example:

from plone.testing import Layer

from plone.app.testing import ploneSite
from plone.app.testing import quickInstallProduct

...

class MyLayer(Layer):

    ...

    def setUp(self):

        ...

        with ploneSite() as portal:
            quickInstallProduct(portal, 'my.product')

            ...

Component architecture sandboxing

pushGlobalRegistry(portal, new=None, name=None)

Create or obtain a stack of global component registries, and push a new registry to the top of the stack. This allows Zope Component Architecture registrations (e.g. loaded via ZCML) to be effectively torn down.

If you are going to use this function, please read the corresponding documentation for zca.pushGlobalRegistry() in plone.testing. In particular, note that you must reciprocally call popGlobalRegistry() (see below).

This helper is based on zca.pushGlobalRegistry(), but will also fix up the local component registry in the Plone site portal so that it has the correct bases.

For example:

from plone.testing import Layer

from plone.app.testing import ploneSite
from plone.app.testing import pushGlobalRegistry
from plone.app.testing import popGlobalRegistry

...

class MyLayer(Layer):

    ...

    def setUp(self):

        ...

        with ploneSite() as portal:
            pushGlobalRegistry(portal)

            ...

popGlobalRegistry(portal)

Tear down the top of the component architecture stack, as created with pushGlobalRegistry()

For example:

...

    def tearDown(self):

        with ploneSite() as portal:
            popGlobalRegistry(portal)

Global state cleanup

tearDownMultiPluginRegistration(pluginName)

PluggableAuthService “MultiPlugins” are kept in a global registry. If you have registered a plugin, e.g. using the registerMultiPlugin() API, you should tear that registration down in your layer’s tearDown() method. You can use this helper, passing a plugin name.

For example:

from plone.testing import Layer

from plone.app.testing import ploneSite
from plone.app.testing import tearDownMultiPluginRegistration

...

class MyLayer(Layer):

    ...

    def tearDown(self):

        tearDownMultiPluginRegistration('MyPlugin')

        ...

Basic content management

To create a content item of type ‘Folder’ with the id ‘f1’ in the root of the portal:

portal.invokeFactory('Folder', 'f1', title=u"Folder 1")

The title argument is optional. Other basic properties, like description, can be set as well.

Note that this may fail with an Unauthorized exception, since the test user won’t normally have permissions to add content in the portal root, and the invokeFactory() method performs an explicit security check. You can set the roles of the test user to ensure that he has the necessary permissions:

from plone.app.testing import setRoles
from plone.app.testing import TEST_USER_ID

setRoles(portal, TEST_USER_ID, ['Manager'])
portal.invokeFactory('Folder', 'f1', title=u"Folder 1")

To obtain this object, acquisition-wrapped in its parent:

f1 = portal['f1']

To make an assertion against an attribute or method of this object:

self.assertEqual(f1.Title(), u"Folder 1")

To modify the object:

f1.setTitle(u"Some title")

To add another item inside the folder f1:

f1.invokeFactory('Document', 'd1', title=u"Document 1")
d1 = f1['d1']

To check if an object is in a container:

self.assertTrue('f1' in portal)

To delete an object from a container:

del portal[‘f1’]

There is no content or workflows installed by default. You can enable workflows:

portal.portal_workflow.setDefaultChain("simple_publication_workflow")

Searching

To obtain the portal_catalog tool:

from Products.CMFCore.utils import getToolByName

catalog = getToolByName(portal, 'portal_catalog')

To search the catalog:

results = catalog(portal_type="Document")

Keyword arguments are search parameters. The result is a lazy list. You can call len() on it to get the number of search results, or iterate through it. The items in the list are catalog brains. They have attributes that correspond to the “metadata” columns configured for the catalog, e.g. Title, Description, etc. Note that these are simple attributes (not methods), and contain the value of the corresponding attribute or method from the source object at the time the object was cataloged (i.e. they are not necessarily up to date).

To make assertions against the search results:

self.assertEqual(len(results), 1)

# Copy the list into memory so that we can use [] notation
results = list(results)

# Check the first (and in this case only) result in the list
self.assertEqual(results[0].Title, u"Document 1")

To get the path of a given item in the search results:

self.assertEqual(resuls[0].getPath(), portal.absolute_url_path() + '/f1/d1')

To get an absolute URL:

self.assertEqual(resuls[0].getURL(), portal.absolute_url() + '/f1/d1')

To get the original object:

obj = results[0].getObject()

To re-index an object d1 so that its catalog information is up to date:

d1.reindexObject()

User management

To create a new user:

from Products.CMFCore.utils import getToolByName

acl_users = getToolByName(portal, 'acl_users')

acl_users.userFolderAddUser('user1', 'secret', ['Member'], [])

The arguments are the username (which will also be the user id), the password, a list of roles, and a list of domains (rarely used).

To make a particular user active (“logged in”) in the integration testing environment use the login method and pass it the username:

from plone.app.testing import login

login(portal, 'user1')

To log out (become anonymous):

from plone.app.testing import logout

logout()

To obtain the current user:

from AccessControl import getSecurityManager

user = getSecurityManager().getUser()

To obtain a user by name:

user = acl_users.getUser('user1')

Or by user id (id and username are often the same, but can differ in real-world scenarios):

user = acl_users.getUserById('user1')

To get the user’s user name:

userName = user.getUserName()

To get the user’s id:

userId = user.getId()

Permissions and roles

To get a user’s roles in a particular context (taking local roles into account):

from AccessControl import getSecurityManager

user = getSecurityManager().getUser()

self.assertEqual(user.getRolesInContext(portal), ['Member'])

To change the test user’s roles:

from plone.app.testing import setRoles
from plone.app.testing import TEST_USER_ID

setRoles(portal, TEST_USER_ID, ['Member', 'Manager'])

Pass a different user name to change the roles of another user.

To grant local roles to a user in the folder f1:

f1.manage_setLocalRoles(TEST_USER_ID, ('Reviewer',))

To check the local roles of a given user in the folder ‘f1’:

self.assertEqual(f1.get_local_roles_for_userid(TEST_USER_ID), ('Reviewer',))

To grant the ‘View’ permission to the roles ‘Member’ and ‘Manager’ in the portal root without acquiring additional roles from its parents:

portal.manage_permission('View', ['Member', 'Manager'], acquire=False)

This method can also be invoked on a folder or individual content item.

To assert which roles have the permission ‘View’ in the context of the portal:

roles = [r['name'] for r in portal.rolesOfPermission('View') if r['selected']]
self.assertEqual(roles, ['Member', 'Manager'])

To assert which permissions have been granted to the ‘Reviewer’ role in the context of the portal:

permissions = [p['name'] for p in portal.permissionsOfRole('Reviewer') if p['selected']]
self.assertTrue('Review portal content' in permissions)

To add a new role:

portal._addRole('Tester')

This can now be assigned to users globally (using the setRoles helper) or locally (using manage_setLocalRoles()).

To assert which roles are available in a given context:

self.assertTrue('Tester' in portal.valid_roles())

Workflow

To set the default workflow chain:

from Products.CMFCore.utils import getToolByName

workflowTool = getToolByName(portal, 'portal_workflow')

workflowTool.setDefaultChain('my_workflow')

In Plone, most chains contain only one workflow, but the portal_workflow tool supports longer chains, where an item is subject to more than one workflow simultaneously.

To set a multi-workflow chain, separate workflow names by commas.

To get the default workflow chain:

self.assertEqual(workflowTool.getDefaultChain(), ('my_workflow',))

To set the workflow chain for the ‘Document’ type:

workflowTool.setChainForPortalTypes(('Document',), 'my_workflow')

You can pass multiple type names to set multiple chains at once. To set a multi-workflow chain, separate workflow names by commas. To indicate that a type should use the default workflow, use the special chain name ‘(Default)’.

To get the workflow chain for the portal type ‘Document’:

chains = dict(workflowTool.listChainOverrides())
defaultChain = workflowTool.getDefaultChain()
documentChain = chains.get('Document', defaultChain)

self.assertEqual(documentChain, ('my_other_workflow',))

To get the current workflow chain for the content object f1:

self.assertEqual(workflowTool.getChainFor(f1), ('my_workflow',))

To update all permissions after changing the workflow:

workflowTool.updateRoleMappings()

To change the workflow state of the content object f1 by invoking the transaction ‘publish’:

workflowTool.doActionFor(f1, 'publish')

Note that this performs an explicit permission check, so if the current user doesn’t have permission to perform this workflow action, you may get an error indicating the action is not available. If so, use login() or setRoles() to ensure the current user is able to change the workflow state.

To check the current workflow state of the content object f1:

self.assertEqual(workflowTool.getInfoFor(f1, 'review_state'), 'published')

Properties

To set the value of a property on the portal root:

portal._setPropValue('title', u"My title")

To assert the value of a property on the portal root:

self.assertEqual(portal.getProperty('title'), u"My title")

To change the value of a property in a property sheet in the portal_properties tool:

from Products.CMFCore.utils import getToolByName

propertiesTool = getToolByName(portal, 'portal_properties')
siteProperties = propertiesTool['site_properties']

siteProperties._setPropValue('many_users', True)

To assert the value of a property in a property sheet in the portal_properties tool:

self.assertEqual(siteProperties.getProperty('many_users'), True)

Installing products and extension profiles

To apply a particular extension profile:

from plone.app.testing import applyProfile

applyProfile(portal, 'my.product:default')

This is the preferred method of installing a product’s configuration.

To install an add-on product into the Plone site using the portal_quickinstaller tool:

from plone.app.testing import quickInstallProduct

quickInstallProduct(portal, 'my.product')

To re-install a product using the quick-installer:

quickInstallProduct(portal, 'my.product', reinstall=True)

Note that both of these assume the product’s ZCML has been loaded, which is usually done during layer setup. See the layer examples above for more details on how to do that.

When writing a product that has an installation extension profile, it is often desirable to write tests that inspect the state of the site after the profile has been applied. Some of the more common such tests are shown below.

To verify that a product has been installed (e.g. as a dependency via metadata.xml):

from Products.CMFCore.utils import getToolByName

quickinstaller = getToolByName(portal, 'portal_quickinstaller')
self.assertTrue(quickinstaller.isProductInstalled('my.product'))

To verify that a particular content type has been installed (e.g. via types.xml):

typesTool = getToolByName(portal, 'portal_types')

self.assertNotEqual(typesTool.getTypeInfo('mytype'), None)

To verify that a new catalog index has been installed (e.g. via catalog.xml):

catalog = getToolByName(portal, 'portal_catalog')

self.assertTrue('myindex' in catalog.indexes())

To verify that a new catalog metadata column has been added (e.g. via catalog.xml):

self.assertTrue('myattr' in catalog.schema())

To verify that a new workflow has been installed (e.g. via workflows.xml):

workflowTool = getToolByName(portal, 'portal_workflow')

self.assertNotEqual(workflowTool.getWorkflowById('my_workflow'), None)

To verify that a new workflow has been assigned to a type (e.g. via workflows.xml):

self.assertEqual(dict(workflowTool.listChainOverrides())['mytype'], ('my_workflow',))

To verify that a new workflow has been set as the default (e.g. via workflows.xml):

self.assertEqual(workflowTool.getDefaultChain(), ('my_workflow',))

To test the value of a property in the portal_properties tool (e.g. set via propertiestool.xml)::

propertiesTool = getToolByName(portal, 'portal_properties')
siteProperties = propertiesTool['site_properties']

self.assertEqual(siteProperties.getProperty('some_property'), "some value")

To verify that a stylesheet has been installed in the portal_css tool (e.g. via cssregistry.xml):

cssRegistry = getToolByName(portal, 'portal_css')

self.assertTrue('mystyles.css' in cssRegistry.getResourceIds())

To verify that a JavaScript resource has been installed in the portal_javascripts tool (e.g. via jsregistry.xml):

jsRegistry = getToolByName(portal, 'portal_javascripts')

self.assertTrue('myscript.js' in jsRegistry.getResourceIds())

To verify that a new role has been added (e.g. via rolemap.xml):

self.assertTrue('NewRole' in portal.valid_roles())

To verify that a permission has been granted to a given set of roles (e.g. via rolemap.xml):

roles = [r['name'] for r in portal.rolesOfPermission('My Permission') if r['selected']]
self.assertEqual(roles, ['Member', 'Manager'])

Traversal

To traverse to a view, page template or other resource, use restrictedTraverse() with a relative path:

resource = portal.restrictedTraverse('f1/@@folder_contents')

The return value is a view object, page template object, or other resource. It may be invoked to obtain an actual response (see below).

restrictedTraverse() performs an explicit security check, and so may raise Unauthorized if the current test user does not have permission to view the given resource. If you don’t want that, you can use:

resource = portal.unrestrictedTraverse('f1/@@folder_contents')

You can call this on a folder or other content item as well, to traverse from that starting point, e.g. this is equivalent to the first example above:

f1 = portal['f1']
resource = f1.restrictedTraverse('@@folder_contents')

Note that this traversal will not take IPublishTraverse adapters into account, and you cannot pass query string parameters. In fact, restrictedTraverse() and unrestrictedTraverse() implement the type of traversal that happens with path expressions in TAL, which is similar, but not identical to URL traversal.

To look up a view manually:

from zope.component import getMultiAdapter

view = getMultiAdapter((f1, request), name=u"folder_contents")

Note that the name here should not include the @@ prefix.

To simulate an IPublishTraverse adapter call, presuming the view implements IPublishTraverse:

next = view.IPublishTraverse(request, u"some-name")

Or, if the IPublishTraverse adapter is separate from the view:

from zope.publisher.interfaces import IPublishTraverse

publishTraverse = getMultiAdapter((f1, request), IPublishTraverse)
next = view.IPublishTraverse(request, u"some-name")

To simulate a form submission or query string parameters:

request.form.update({
        'name': "John Smith",
        'age':  23
    })

The form dictionary contains the marshalled request. That is, if you are simulating a query string parameter or posted form variable that uses a marshaller like :int (e.g. age:int in the example above), the value in the form dictionary should be marshalled (an int instead of a string, in the example above), and the name should be the base name (age instead of age:int).

To invoke a view and obtain the response body as a string:

view = f1.restrictedTraverse('@@folder_contents')
body = view()

self.assertFalse(u"An unexpected error occurred" in body)

Please note that this approach is not perfect. In particular, the request is will not have the right URL or path information. If your view depends on this, you can fake it by setting the relevant keys in the request, e.g.:

request.set('URL', f1.absolute_url() + '/@@folder_contents')
request.set('ACTUAL_URL', f1.absolute_url() + '/@@folder_contents')

To inspect the state of the request (e.g. after a view has been invoked):

self.assertEqual(request.get('disable_border'), True)

To inspect response headers (e.g. after a view has been invoked):

response = request.response

self.assertEqual(response.getHeader('content-type'), 'text/plain')

Simulating browser interaction

End-to-end functional tests can use zope.testbrowser to simulate user interaction. This acts as a web browser, connecting to Zope via a special channel, making requests and obtaining responses.

Note: zope.testbrowser runs entirely in Python, and does not simulate a JavaScript engine.

Note that to use zope.testbrowser, you need to use one of the functional testing layers, e.g. PLONE_FUNCTIONAL_TESTING, or another layer instantiated with the FunctionalTesting class.

If you want to create some initial content, you can do so either in a layer, or in the test itself, before invoking the test browser client. In the latter case, you need to commit the transaction before it becomes available, e.g.:

from plone.app.testing import setRoles
from plone.app.testing import TEST_USER_ID

# Make some changes
setRoles(portal, TEST_USER_ID, ['Manager'])
portal.invokeFactory('Folder', 'f1', title=u"Folder 1")
setRoles(portal, TEST_USER_ID, ['Member'])

# Commit so that the test browser sees these changes
import transaction
transaction.commit()

To obtain a new test browser client:

from plone.testing.z2 import Browser

browser = Browser(app)

To open a given URL:

portalURL = portal.absolute_url()
browser.open(portalURL)

To inspect the response:

self.assertTrue(u"Welcome" in browser.contents)

To inspect response headers:

self.assertEqual(browser.headers['content-type'], 'text/html; charset=utf-8')

To follow a link:

browser.getLink('Edit').click()

This gets a link by its text. To get a link by HTML id:

browser.getLink(id='edit-link').click()

To verify the current URL:

self.assertEqual(portalURL + '/edit', browser.url)

To set a form control value:

browser.getControl('Age').value = u"30"

This gets the control by its associated label. To get a control by its form variable name:

browser.getControl(name='age:int').value = u"30"

See the zope.testbrowser documentation for more details on how to select and manipulate various types of controls.

To submit a form by clicking a button:

browser.getControl('Save').click()

Again, this uses the label to find the control. To use the form variable name:

browser.getControl(name='form.button.Save').click()

To simulate HTTP BASIC authentication and remain logged in for all requests:

from plone.app.testing import TEST_USER_NAME, TEST_USER_PASSWORD

browser.addHeader('Authorization', 'Basic %s:%s' % (TEST_USER_NAME, TEST_USER_PASSWORD,))

To simulate logging in via the login form:

browser.open(portalURL + '/login_form')
browser.getControl(name='__ac_name').value = TEST_USER_NAME
browser.getControl(name='__ac_password').value = TEST_USER_PASSWORD
browser.getControl(name='submit').click()

To simulate logging out:

browser.open(portalURL + '/logout')

browser.handleErrors = False

from Products.CMFCore.utils import getToolByName

errorLog = getToolByName(portal, 'error_log')
print errorLog.getLogEntries()[-1]['tb_text']

open('/tmp/testbrowser.html', 'w').write(browser.contents)

4.2.7 (2018-10-05)

Bug fixes:

• Amended the doctests to work with automatical layer port picking from plone.testing. [Rotonen]

4.2.6 (2017-05-09)

Bug fixes:

• Do not load Products.SecureMailHost zcml. It is not needed in Plone 4. [frisi]

4.2.5 (2015-03-17)

• Add Members folder, if it is not there in test layer [tomgross]

4.2.4 (2014-02-11)

• Add ‘ROBOT_TEST_LEVEL’ to interfaces, so other packages can import it. This makes things easier if we decide to change the value. [timo]

4.2.3 (2014-01-28)

• Sync bbb PloneTestCase class with original one but don’t install ATContentTypes profile [tomgross]

• Fire an event notification to ensure setup of browser and skin layers Fixes https://dev.plone.org/ticket/11673 [do3cc]

4.2.2 (2013-02-09)

• Add [robot] extras for requiring dependnecies for Robot Framework tests with Selenium2Library [datakurre]

• Install PythonScripts as zope product [mikejmets]

4.2.1 (2012-12-15)

• Allow testing with non standard port. Allows running multiple test suites in parallel. [do3cc]

• Documentation updates. [moo]

4.2 (2012-04-15)

• Branch as 4.2 as the plone.app.collection addition breaks backwards compatibility. [esteele]

• Fixed spurious failure in our own tests by using a longer timeout. [maurits]

• plone.app.collection added to PloneFixture. [timo]

4.0.2 (2011-08-31)

• Load ZCML before installing Zope products in PloneWithPackageLayer; it enables package registration. [gotcha]

4.0.1 (2011-07-14)

• Add additional_z2_products parameter to PloneWithPackageLayer helper class to install additional Zope 2 products. [jfroche]

4.0 - 2011-05-13

• 4.0 Final release. [esteele]

• Add MANIFEST.in. [WouterVH]

4.0a6 - 2011-04-06

• Added helper functions for selenium layer. (Copied from SeleniumTestCase within Products.CMFPlone/Products/CMFPlone/tests/selenium/base.py) [emanlove]

• Rework layer setup of SeleniumLayer so that z2.ZSERVER_FIXTURE is a default_base. [esteele]

• Convert the passed-in selenium webdriver name to lowercase before doing a module lookup. [esteele]

• Moved selenium start up and tear down to testSetUp and testTearDown, respectively. This was done to help further isolate individual tests. For example, logging in under one test would require either logging out or shutting down the browser, which is what the selenium_layer will now do under testTearDown, in order to have a “clean” state within the next test. [emanlove]

• Corrected module path for the various selenium webdrivers using selenium 2.0b2. [emanlove]

4.0a5 - 2011-03-02

• Use the new plone.testing.security module to ensure isolation of security checkers when setting up and tearing down layers based on the PloneSandboxLayer helper base class. This would cause problems when running multiple test suites in the same test run, in particular if one of those suites were setting up ZCML that used five.grok. [optilude]

4.0a4 - 2011-01-11

• Automatically tear down PAS registrations via snapshotting when using PloneSandboxLayer. It’s too difficult to do this manually when you consider that plugins may be registered in ZCML via transitive dependencies. There should be no backwards compatibility concern - using tearDownMultiPlugin() is still supported, and it’s generally safe to call it once. [optilude]

• Try to make sure tearDownMultiPlugin() and the generic PAS plugin cleanup handler do not interfere with the cleanup handler from the PAS ZCML directive. [optilude]

• Do not install Products.kupu or Products.CMFPlacefulWorkflow. [elro]

• Depend on Products.CMFPlone instead of Plone. [elro]

4.0a3 - 2010-12-14

• Allow top-level import of PloneTestLifecycle. [stefan]

• Added a warning not to use ‘default’ Firefox profile for selenium tests. [zupo]

• Fixed distribution dependency declarations. [hannosch]

• Correct license to GPL version 2 only. [hannosch]

• Make some module imports helper methods on the already policy-heavy helper class per optilude’s suggestion. [rossp]

• Add a layer and test case for running selenium tests. [rossp]

• Give the default test user differing user id and login name. This helps reveal problems with userid vs login name errors, an overly common error. [wichert]

1.0a2 - 2010-09-05

• Make sure plone.app.imaging is installed properly during layer setup. [optilude]

1.0a1 - 2010-08-01

• Initial release