pear:qa:ci

This is an old revision of the document!


PEAR QA Continuous Integration and Unit Tests

There are a number of tools qa use to maintain quality.

PHPCS and General QA tools

Cruise Control

Cruise Control is a continuous integration platform. Currently, all packages in both PEAR and PEAR2 are built by it.

The build task does:

  1. Update svn
  2. Run $ phpunit --log-junit ... tests/AllTests.php (if AllTests.php is present)
  3. Run $ phpunit --log-junit ... tests/ (if .phpt is present)
  4. Run $ phpmd path/to/package/trunk xml codesize,unusedcode,naming --reportfile ...
  5. Run $ phpcpd path/to/package/trunk --log-pmd ...
  6. Run $ phpcs --report=checkstyle --standard=PEAR --ignore=tests path/to/package/trunk
  7. Build the package with Pyrus $ php /path/to/pyrus.phar package -o .../trunk.tar.gz

If either the unit tests or building the package fails, the build is marked as a failure.

A file, called trunk.tar.gz is created as a build artifact.

How do I make sure my tests work?

In general, we encourage the use of an AllTests.php - we target PHPUnit 3.4 at this time.

Your package directory layout should allow you to successfully run your test suite as below:

$ cd Foo_Bar/trunk
$ php tests/AllTests.php

... or as per the phpunit command above.

My directory layout doesn't work

A common pattern with older packages is to have a directory structure which is unlike the installed package layout. IE: Foo_Bar/trunk/Bar.php. Most authors make use of the baseinstalldir attribute in the package.xml, or only run tests after installation

To fix this:

$ svn mkdir Foo
$ svn mv Bar.php Foo/
# Edit package.xml, change baseinstalldir to /
$ vim package.xml
 
# Rebuild package using PEAR_PackageFileManager_CLI
$ pfm
 
# Run tests to confirm no fatal errors, using one of
$ php tests/AllTests.php
$ pear run-tests -r tests/
$ phpunit tests/
$ phpunit tests/AllTest.php
 
# Commit
$ svn commit -m "Updated directory layout"

Pyrus won't build my package 1.0

See migration

My unit tests need a (database/server/setup/configuration)

Two strategies exist for this: - Making use of PHPUnit's mocking capabilities or utilising something like HTTP_Request2's Mock Adapter - Checking your environment and skipping the test if it cannot run

Todo

  1. Fix how pear2-packages-all and pear2/all relate to the test suite
  2. Generate a changelog, package.xml file (possibly in pearweb, possible on the command line) automatically; and build off of that.
  3. Investigate what's up with the Metrics and other Cruise Control errors
  4. Investigate a notification task to package maintainers?
  5. Investigate allowing bootstrapped build.xml files back in (Pyrus)
  6. Upgrade PHP on test.pear.php.net
  7. Install xdebug for proper code coverage

How to test a new PEAR release

Before releasing a new version of PEAR, we need to make sure it runs on as many systems as possible. It's pretty easy:

  1. Install the new PEAR (1.7.0RC2 currently)
  2. Make sure you have the XML_RPC package
  3. Checkout pear-core from CVS to get the tests
  4. Run the tests
pear upgrade -f PEAR
pear upgrade XML_RPC
cvs -d :pserver:cvsread@cvs.php.net:/repository checkout pear-core
cd pear-core/tests && pear run-tests -r

Tell pear-qa@lists.php.net if you got failures, and if, which tests did not pass. We will come back to you in that case.

Common pitfalls

  • Make sure that PHP is compiled with tokenizer support (--enable-tokenizer). On most systems this is default, but on Gentoo Linux for instance, you need to enable the tokenizer USE flag.
  • For some tests the executable php-cgi is needed. In some Linux distributions this is contained in a separate package, but on for instance Gentoo Linux this has to be enabled using the cgi USE flag.
  • If running on linux, do not run the tests as root
pear/qa/ci.1314246746.txt.gz · Last modified: 2017/09/22 13:28 (external edit)