This repository contains a number of configuration files for using zc.buildout to quickly set up a testing/development environment for your package.

A good example of how to use this, is bobtemplates.plone. Follow the instructions there to create a Plone add-on, and look at the created files, especially the various buildout configs and .travis.yml.

The intended usage is to create a buildout.cfg like:

[buildout]
extends = https://raw.githubusercontent.com/collective/buildout.plonetest/master/test-5.x.cfg
package-name = plone.app.foo

Create a virtualenv and run buildout. This should give you a bin/test script, which can be used to run your package's tests. If your tests have additional dependencies, you should declare them via the extras_require parameter of setuptools.setup and refer to the key used using the package-extras variable:

[buildout]
extends = https://raw.githubusercontent.com/collective/buildout.plonetest/master/test-5.x.cfg
package-name = plone.app.foo
package-extras = [test]

If you want to do continuous integration with Travis CI you can use this same buildout config. And a .travis.yml like:

version: ~> 1.0
import: collective/buildout.plonetest:travis/default.yml
python: "2.7"
env: PLONE_VERSION=5.2

Include the following in your buildout configuration to create an i18ndude helper script to update the po files of your product:

[buildout]
extends =
    https://raw.githubusercontent.com/collective/buildout.plonetest/master/test-5.x.cfg
    https://raw.githubusercontent.com/collective/buildout.plonetest/master/qa.cfg
package-name = plone.app.foo
package-extras = [test]
parts+=
    i18ndude
    rebuild_i18n-sh

After running bin/buildout you will find a bin/rebuild_i18n.sh; run the script and the po files will be updated.

Domain name is taken from the ${buildout:package-name} variable. The plone domain is also included.

Update your .travis.yml file with the following:

before_script:
  - export DISPLAY=:99.0
  - sh -e /etc/init.d/xvfb start

The buildout.cfg file in your package should look like this:

[buildout]
extends =
    https://raw.githubusercontent.com/collective/buildout.plonetest/master/test-5.x.cfg

package-name = collective.foo
package-extras = [test]

[versions]
setuptools = 41.2.0
zc.buildout = 2.13.2

The versions are optional, but they can help in avoiding restarts when buildout tries to upgrade itself to a version pinned in Plone. It is fine to start without them, but when you run into problems in Travis CI, consider adding them. In this way, all Plone versions use the same buildout and setuptools versions.

These versions match a requirements.txt like this:

setuptools==41.2.0
zc.buildout==2.13.2

The .travis.yml file should look like this:

version: ~> 1.0
import: collective/buildout.plonetest:travis/default.yml
matrix:
  include:
    - python: "2.7"
      env: PLONE_VERSION="4.3"
    - python: "2.7"
      env: PLONE_VERSION="5.1"
    - python: "2.7"
      env: PLONE_VERSION="5.2"
    - python: "3.7"
      env: PLONE_VERSION="5.2"

The trick here is to replace the extended configuration with the right one using the sed command.

If you want to add Quality Assurance to your continuous integration you can update your buildout.cfg file like:

[buildout]
extends =
    https://raw.githubusercontent.com/collective/buildout.plonetest/master/test-5.x.cfg
    https://raw.githubusercontent.com/collective/buildout.plonetest/master/qa.cfg
package-name = plone.app.foo
package-extras = [test]
package-min-coverage = 80
parts+=
    createcoverage
    coverage-sh
    code-analysis

and add and commit .coveragerc file (see example at https://github.com/plone/plone.recipe.codeanalysis/blob/master/.coveragerc)

and update your .travis.yml like:

language: python
python: 2.7
cache:
  pip: true
  directories:
    - eggs
env:
  - TARGET=test
  - TARGET=coverage.sh
before_install:
  - virtualenv -p `which python` .
  - bin/pip install -r requirements.txt
  - bin/buildout -N -t 3 annotate
install:
  - bin/buildout -N -t 3
script:
  - bin/$TARGET