TDD: Test behaviors, not methods

What I observed when a developer tests methods instead behavior
One of my favorite books, Growing Object Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce mentions that you should test behavior, not methods. The book, also referred to many as "GOOS", states on page 43:

We do better when we focus on the features that the object under test should provide, each of which may require collaboration with its neighbors and calling more than one of its methods.  We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code.

 When this advice isn't followed
A few years ago, I coached a fellow developer in TDD.  Although I showed how to "write the code you wish you had" and how the tests drive the design, they refused to write the tests first, which is okay -- it was a big improvement from before when there were no tests.

My observations were that the specs described methods, and it was hard to figure out what the class actually did.  Also, one of the core behaviors of the class was never tested!

Another problem was when my team and I wanted to actually use an instance of the class, we couldn't quickly figure out which method, or set of methods, we should call to get the job done.  The specs read like a list of methods, not how an instance actually behaved.

What are your experiences? Do you prefer to test methods, or behavior?

Proxy Pattern -- one way out of many towards Clean Architecture

Earlier this year, I bought several of the Clean Coders screencasts, which motivated me to implement a clean architecture in Rails.  It also motivated me to read Uncle Bob's classic text, Agile Software Development: Principles, Practices, and Patterns. I've known about the SOLID principles, but the book really shines once you read past those initial chapters.


For example, here's a great quote from Uncle Bob Martin's PPP, regarding the PROXY pattern:

"It is a way to keep the business rule assets of your project separate from the implementation mechanisms that are currently in vogue." (page 345)

However, this isn't the only way to accomplish this. After reading and understanding the principles in the book, I've found that:

• By following the D in the SOLID principles (Dependency Inversion Principle), it naturally leads you to design principles such as the PROXY pattern.
• You have no fear of frameworks polluting your code because the SOLID principles will ensure that the dependencies point in the correct direction
• Your tests will run extremely fast
• The only slow tests you have will be integration tests with external resources (database, web services, file system, etc.) and frameworks
• It's easier to upgrade since you only need to worry about integration failures, not the interaction between business logic and the new framework API. 

If you haven't read the entire book yet, I highly recommend checking it out.  It will change the way you think about writing software forever.