Differences between revisions 1 and 4 (spanning 3 versions)
Revision 1 as of 2005-06-30 01:23:23
Size: 11540
Editor: MaikRoeder
Revision 4 as of 2008-11-15 14:01:02
Size: 11540
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

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

  • These tests should best be placed in ATContentTypes, but to get started we can make adding and editing them part of our functional test suite:
  • Document
  • Event
  • File
  • Folder
  • Image
  • Folder
  • Large Plone Folder
  • Link
  • News Item
  • Topic Use cases:
    • Member adds one of the content types Member adds Favorite
    There are a few parts in Plone that treat specific content types in a special way, and these places should become evident in the functional tests. For example Links and Images, additional information is shown in plone_templates/folder_listing.pt We can take the test a step further and study what happens when you remove a content type altogether.

Portal Catalog

  • The portal catalog contains indexes and metadata which would merit some special attention. Questions to address: What happens when the catalog is empty? What happens when you delete content in the ZMI find it through the catalog?


  • The MailHost is not a standard tool in the Plone sense, so it behaves just a bit differently. In addition, the MailHost is also a place where we are relying on a external service, so we have to take some extra care. One use case would be that there is a temporary problem with sending mail,

    and the administrator has to have a way to switch off the MailHost. He could remove it altogether, and once the problems are resolved, the MailHost is added back in again. This opens a feature request allowing to being able to desactivate a MailHost instead of having to delete it. Some questions we should address here:

    - What happens when we remove the MailHost altogether?

    • - Should related buttons and interfaces still be active?
      • - Can users still access the interface for sending mail? - Is prefs_mailhost_form still showing the configuration?
      - Create functional tests showing what breaks in Plone after removing the
      • MailHost, and then put it back in to see that the tests pass

    - What happens when the Mailhost is not correctly configured?

    - What happens when the MailHost can not send Mail? - Is there something that could have broken while moving from MailHost


Plone Site Permission encapsulation

  • There should be a way to encapsulate a Plone site so that it does not use acquisition at all. This would make Plone immune to Permission changes outside of its scope. This does not cover the case where permissions are actually added to Plone. It also does not cover the case where a product changes permissions during installation or uninstallation. This is also a way to clearly state in one place what the permissions in Plone should be instead of having to take into account acquisition. A fun way to test this is to look for what switching off acquisition breaks, writing tests for that, and then fixing the permissions in Plone until the resulting permissions are the same as they would be by acquisition.


  • We need basic tests for workflows. This work has already started in the

    PloneSelenium product. The idea is to add folders in the different workflow states and to verify whether users with certains roles should have access. The access to a folder can mean different things. The view changes in depending on the "View", "Access Contents", "Modify portal contents" and "List folder contents" permissions and possibly some others as well. This is all very important to have documented by some functional tests. The next part is the plone_workflow, where we have to create a content and make sure that actions and views on the content are respecting permissions. Workflow transitions in plone_workflow

    • pending Waiting for reviewer
      • hide (Member makes content private) publish (Reviewer publishes content)
        • reject (Reviewer rejects submission) retract (Member retracts submission)
      private Visible and editable only by owner
      • show (Member makes content visible)
      published Public
      • reject (Reviewer rejects submission) retract (Member retracts submission)
    • visible Visible but not published
      • hide (Member makes content private) publish (Reviewer publishes content) submit (Member requests publishing)
    Workflow transitions in folder_workflow
    • private Visible and editable only by owner
      • publish (Reviewer publishes content) show (Member makes content visible)
      published Public
      • hide (Member makes content private) retract (Member retracts submission)
    • visible Visible but not published
      • hide (Member makes content private) publish (Reviewer publishes content)
    Workflow Security on plone_workflow
    • View private document View submitted document View visible document View published document
    Workflow Security on folder_workflow
    • View private folder View published folder View visible folder


  • Anonymous joins

    -> Look at CMFMember ftests


  • Member logs in Member forgot his password Member logs out Member wants Plone to remember his name Member does not want Plone to remember his name


  • Member edits Preferences Anonymous searches Members


  • Anonymous access Change default skin Change REQUEST variable name Allow arbitrary skins to be selected Disallow arbitrary skins to be selected Activate Skin Cookie persistence Desactivate Skin Cookie persistence


  • Anonymous searches


  • Admin accesses configlet


  • Admin installs a product Admin uninstalls a product

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

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