Introduction

This page contains ideas and suggestions on how to improve unit tests for the enpraxis.educommons product. A more superficial review is available here.

Install testing

Existing tests for the installation procedure are in the enpraxis.educommons.tests.test_case_install module. Those tests are unit integration tests and could be used as examples to test other installation related code.

One thing to take into account when testing Plone products installation is that a big part of what the product does at install time is not in Python code, but in Generic Setup profiles. These profiles are composed of a bunch of XML files. This means, among other things, that untested (XML) code in profiles it is not reported by using the '--coverage' option from zope.testing. Nevertheless, we need to write tests for Generic Setup profiles as they provide an important part of the product behavior.

Bellow there is a list of installation related items that require testing:

• Workflows assignments, i.e. what is the workflow associated with a content type. This is, in part, covered indirectly, but it's better to explicitly test it.
• Properties on content types like if they are globally addable, the types that can be added inside for folderish content types, additional view methods, default view name
• Collections' criteria added by the product.
• Default permissions for the roles added by the product.

Object creation testing

There are existing tests for object creation in the enpraxis.educommons.tests.test_case_object_create module. All the tests in this module leave the container object in the initial state of the workflow. Since creation permissions are dependent on workflow states, it would be good to test object creation for different workflow states of the container object.

Object editing testing

The object's editing is tested in the enpraxis.educommons.tests.test_case_object_edit module. Currently this module contains a very big test method that walks through all the workflow states for objects using the content_workflow workflow and testing editing permissions for the custom roles defined in the product. This is closer to a functional test than to a unit test. Given the test complexity, it is probably better to move this test to a doctest style test where we could add comments between code lines explaining what the code is doing. At the same time we should continue to write unit integration tests for object editing. Here are some suggestions to write unit integration tests on this matter:

• Split the editing test in several small and specific unit tests. For example, write separate methods to test that producers can edit courses in in-progress state and that members cannot edit content in public state.
• Use the assertRaises method to test that a callable will raise an exception.
• Write a helper method that takes a role and an object and tests if a user with the given role can edit the given object.

Here there is a document with some helper methods to refactor the tests on this matter.

Object deletion testing

There are tests for object deletion in the enpraxis.educommons.tests.test_case_object_remove module. Most tests in this module leave the container object in the initial state of the workflow. Since creation permissions are dependent on workflow states, it would be good to test object deletion for different workflow states of the container object.

Workflow testing

Permissions over workflow transitions are extensively tested in the enpraxis.educommons.tests.test_case_workflow_authorization module. There is something that could make the testing code easier to read and maintain: split big test methods in several small methods that test something very specific. To give a specific example, consider the _testContentObjectAsAdministrator method. Rather than testing that administrators have all the transitions available in a this method, it could be splited in severla methods, each of them testing a particular transition. There is a similar situation with methods _testNotAllowedDepartmentActions and _testNotAllowedCourseActions.

Zope 3 view testing

There are a few test modules to test Zope 3 views, but in general this is an area where a lot of more tests should be added. The existing tests are using plone.mocktestcase and we should continue to use it when adding more tests on this area.

Other untested code

There are some areas and functionalities that are not being covered by unit tests:

• Upgrades from previous versions.
• View permissions.

Too see all this stuff priorized, take a look at UnitTestsRoadmap.