Automated Testing Patterns and Smells

Gerard Meszaros gave a good talk at Goople on how to properly design unit tests:

http://www.youtube.com/watch?v=Pq6LHFM4JvE

His tome (and at 900+ pages, that's a fitting term) covers the unit testing topic from the perspective of identifying smells to help inch in the direction of well-structured tests and patterns that codify the structure that yields quality tests.

Good quality tests

1. bring confidence that the software under test (SUT) works as expected -- "verification"
2. are easy to read and understand -- "maintainability by way of discoverability"
3. are relatively inexpensive to maintain (and write new ones).

Why Poorly Design Tests are Worse Than No Tests

Gerard Meszaros gives a good case for why you should care: namely that just writing tests isn't good enough because you can quickly increase the carry cost of the software if you don't design your tests.  In that case, it would be better not to have written the tests in the first place.

Contributions

Meszaros identifies three categories of testing smells:

1. code smells
2. behavior smells
3. project smells

(of which he spoke of the first two in his talk)

In his book, xUnit Test Patterns: Refactoring Test Code, Meszaros identifies a number of categories of patterns:

Chapter 18 Test Strategy Patterns 

Chapter 19 xUnit Basics Patterns 

Chapter 20 Fixture Setup Patterns 

Chapter 21 Result Verification Patterns 

Chapter 22 Fixture Teardown Patterns 

Chapter 23 Test Double Patterns 

Chapter 24 Test Organization Patterns 

Chapter 25 Database Patterns 

Chapter 26 Design-for-Testability Patterns 

Chapter 27 Value Patterns

---

I'm purchasing this book and expecting to get the following benefits:

• develop a more academic understanding of the design of tests;  having patterns in mind while coding are excellent guides -- if you don't know the core patterns, you're swinging blind, relatively speaking.
• improve the quality of my tests by developing a sense for how they can go wrong and why.  This means getting a grasp of the dynamic complexity of making a "mistake" in test design and knowing the cost that incurs later.  This is the essence of informed design decisions.
• also this is a handy skill for tackling legacy code.