Initial Testing Plan for Plone

To come up with an initial testing plan, different approaches have been explored.

The first idea is to try to make Plone choke on some weird input in the forms or even by configuring Plone wrong on purpose.

It is also good to try to break stuff by simply removing it altogether to see how Plone reacts. This actually reveals what it is that the removed component is important for, and guides the writing of functional tests for it. As a side effect, a lot of thinking is provoked about how things are currently working, possibly revealing annoying hard-coded behaviour and pointing into directions for making the application more reliable or at least fail gracefully.

Unit tests are not sufficient in some use cases, and it sometimes even happens that we have to rewrite some unit tests as functional tests in order to have better coverage in face of Plone site customisations. In the best case these changes could always be fed back to customisation policies, but we have to test for the worst case, where in-depth changes for example to the permissions are made, and we need to ensure that there are functional tests that make problems directly evident.

Basic Content types tests

Portal Catalog

MailHost

Permissions

Plone Site Permission encapsulation

Workflow

RegistrationTool

MembershipTool

MemberDataTool

SkinsTool

CatalogTool

Configlets

QuickInstallerTool

InitialTestingPlan (last edited 2008-11-15 14:01:02 by localhost)

Unable to edit the page? See the FrontPage for instructions.