Guidelines for writing and organising and designing Agile tests?

I need a little help for a course I'm preparing which introduces Agile to a group of experienced Testers.  I'd like to give them some "guidelines" for writing tests they have to live with.

• Way back in my 3rd year at university our software engineering gave us a list of 6 - 10 "rules" or guidelines about how to write good code.  I can't recall the list fully, but one of them was "no gotos", another "no downward passed control", and I'm sure it had something about low coupling and high cohesion.  
• The same lecturer - Matt Humphries was his name - also got us to read Strunk and White, to improve our writing.  Active voice rules ... 
•   There are different guidelines today such as DRY (Don't repeat yourself) and YAGNI (You ain't gonna need it).
•   In Database Design we have similiar rules of design - such as the normal forms used in transactional databases and the snowflake design used in datawarehousing.

But ... I'm interested if there are any similiar rules for writing tests automated tests usign tools like Cucumber or Fit.  The closest I've seen is Dave Peterson's excellent presentation on Readability.

Have you seen or written something similiar which you could share?