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?
No comments:
Post a Comment