Q:

How to test Plone addon on Travis CI

Currently there has been movement to start continuous integration of Plone addons on Travis CI service. I have seen a lot of packages doing their own this and that testing, from running unit tests to do source code linting of merge requests. I see this healthy development as it takes the pain of setting up your own test runner and makes it easier for less Python-sawy community members to have tests run for their patches. 
However, I have not found a definite guide of best practices how one should test his/her addon on Travis CI. At least in my case this has resulted to cargo cult programming and copy-pasting code from other random addons, because I don't know what's available and how one should do it.
Could authors, who have insight how Travis CI and Plone testing works clarify

What kind of tests you should run on Travis CI
How you should run these tests, in particulary in the context of collective package
What are the best examples you should look into
Where these practices are or should be documented*
How one should test against multiple Plone versions, or is it possbile
Where to pipe the result? Personal email?

*) Traditional Finnish carrot provided for those who open their text editor and spend five minutes to dump the contents of their brain

A:

What kind of tests you should run on Travis CI

All collective or other packages that are not in the Plone core and not already tested on jenkins.plone.org.

How you should run these tests, in particulary in the context of collective package

http://datakurre.pandala.org/2012/09/speed-up-your-plone-add-on-tests-on.html
See also Nejc's talk:
http://de.slideshare.net/zupo/travis-ci-fun-and-easy-ci-for-your-plone-packages

What are the best examples you should look into

These packages all use the approach described in Asko's blogpost:
https://github.com/collective/collective.mailchimp
https://github.com/plone/plone.act
https://github.com/plone/plone.app.collection

Where these practices are or should be documented*

The testing team is currently working on a testing documentation that will include travis ci best practices.

How one should test against multiple Plone versions, or is it possbile

This should be possible. I'm not sure anybody tried that yet though. Maybe somebody else is able to answer that question.

Where to pipe the result? Personal email?

I guess that depends on the package. I currently use my personal email address for collective packages I'm working on.

A:

How one should test against multiple Plone versions, or is it possbile

plone.api tests against different Python (2.6 & 2.7) and Plone (4.2 & 4.3) versions: https://github.com/plone/plone.api/blob/master/.travis.yml

Where to pipe the result? Personal email?
  If you leave the email notification empty, it will email the person who triggered the build (aka. the last commiter). I find this a sane default.

Apart from that I always post a message to IRC channel: #niteoweb for packages we maintain, #client for client work we do, #sprint for plone.api (this one needs to change, Plone needs a CI channel where we can post such notifications). 

