Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

HELP WANTED! If you have written testing standards previously, please read the guidelines below, and help author testing standards for the Zend Framework.

Why use unit tests?

Components will not be included in Zend Framework releases without a reasonable collection of working unit tests. This includes incubator components.

Test Standard Goals

We are moving towards continuous integration and are looking at having a build/test server (build docs, api docs and run tests) responding on check-in similar to CruiseControl.

  • Sane defaults
    • default database names, usernames, passwords, etc. should not conflict with existing ones
    • desired [database] account restrictions and access should be included
    • include example database creation scripts for each of the tested database engines
    • reports produced in less than 15 minutes on typical systems
  • All tests work out of the box, with minimal configuration
  • Test startups and teardowns should be "smart" with persistent data, such that restarting the testing process works, regardless of possibly aborted previous tests.
  • Zend_Environment runs first (to determine if the environment meets minimum ZF requirements)

How often should code be svn'ed ?

Released Components (including released incubator components)

Avoid breaking existing functionality.

Commit your changes as often as code is completed and tested successfully. No code should enter the repository that is not tested, but you also may not want to hold off on committing large chunks of work that are incomplete, and in this case, interstitial commits should be acceptable, so long as they do not break existing functionality.

Unrelease Incubator Components

Prior to the first public release of an incubator component, incubator contributors should commit early and often, regardless of unit tests and documentation completion. Indeed, documentation will require reworking as often as the API changes, and it is unnecessary to have to do this reworking for incubator components not yet selected for release
in the core framework. Although most consider testing while developing best practice, it is more important that code enter the repository on a daily basis for enabling review and continuous work by other framework contributors. That is, incubator contributors should commit their outstanding work on a daily basis, whether it is "complete" or not, until the component is selected for inclusion with a public release of the Zend Framework (including a publicly released incubator component). After the time when a component is selected for release, the more strict policy of committing only unit-tested code would apply, and the API should stabilize enough for writing documentation to be
included with the release.

Zend Framework Testing Standards Best Practice

Please contribute.

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.