• specify what, not how
• running tests in a transaction, rollback after
• i have a diagram for a rule of thumb that gives you a good answer on which fixture to use. will try to put it into an electronic form
• given - when - then general test flow (setup-action-check) (arrange/act/assert)
• using .parse for custom domain types

• anything to do with action fixture
• too many columns
• too long tests
• lots of different things checked in a single test
• execution flow (using tables to manipulate data instead of encapsulating that into fixtures)
• tightly coupled tests
• Lots of HTML Parsing

Also, to make sure we don't get to heavy into the Good/Bad concept, maybe we should have some higher level themes. Like Patterns for Data Tests, Patterns for UI Tests, etc