Dale Emery gave a talk at Agile Development Practices 2009 and has released an accompanying paper to it.

Read it.

Now, it is Acceptance Test focused, but you its lessons are applicable to ‘regular’ tests as well.

  • The difference between success and failure is not the maintenance costs per se, but whether the organization expects them.
  • incidental details, details required only because of the way we’ve chosen to implement the system and the test. Incidental details destroy maintainability.
  • So let’s create a keyword to hide some of the incidental details. Adam – DSL!
  • At the expense of a little bit of syntax awkwardness in the keyword definition, we’ve gained a lot of clarity in the test. It’s a tradeoff well worth making.
  • Duplication often signals that some important concept lurks unexpressed in the tests. That’s especially true when we duplicate not just single steps, but sequences of steps.
  • By analyzing duplication in the test, we identified two essential system concepts — the system accepts valid passwords and rejects invalid ones. By defining keywords, we named those concepts
  • By putting names to those concepts, and using the names throughout the test, we made the test more understandable and thus more maintainable.
  • Any time spent puzzling out the meaning and significance of a test is maintenance cost.
  • … these “trivial” maintenance costs add up, and they kill test automation efforts.
  • I can create a variable, give it an expressive name, and assign it a value that embodies that name.
  • I can understand at a glance the meaning and significance of each test and each step.