I've been thinking about the role that stories played compared to specs, and that "should we use should" thread brought those thoughts up again.
First I want to discuss whether or not specs are authoritative regarding the desired behavior of a system. I would say they're a good approximation of how the system currently runs according to the developer's understanding. I say they're an approximation because if you use mocks everywhere (as I believe you ought to) then you're not performing integrations and the specs are necessarily incomplete. Why does that idea matter? Traditionally, we've leaned heavily on a suite of unit tests to perform refactorings. In fact, Fowler says the first thing you have to do in order to refactor is grow a set of comprehensive unit tests. Refactoring, by definition, is changing the structure without changing the observable behavior. Implicit in using tests to enable refactoring is the idea that those tests precisely define what the behavior of a system should be. If we say that our specs are not actual specifications of desired behavior, then specs aren't sufficient safety nets for refactoring. This mostly comes from my experience that refactoring is often a PITA when using mocks. Mocks isolate dependencies, which is great, and makes it easy to change code without affecting parts of the system that really shouldn't be affected. However they make simple, standard refactorings like "move method" more difficult. If I say that stories are authoritative and specs aren't, then that means I ought to rely on stories to provide the safety net for my refactoring. When taking those baby steps, it's important to keep the stories green rather than the specs. Another result of this thinking is that more specification should be done in stories than I originally thought. Edge cases are my prime example. I used to think I should write a story that expresses the general desired behavior, and then cover any edge cases in specs. However edge cases should be covered by stories because stories define the desired behavior of the system. Also, edge cases presumably represent some business value to the customer. Finally, it's better to keep all of the desired behavior specs in one place. Stories are naturally more verbose than specs though. That paragraph feels awkward to me, because I think I'm missing some vocabulary. It suggests to me that the collection of all user stories is the app specification - "spec" for short. What is the collection of all descriptions, the object-level specs? I've always just said "specs," but I don't think that really fits anymore with my current thinking. Not to mention it's just confusing if I also use "spec" to mean the collection of all user stories. I know that an individual describe block is a "description," but maybe the whole suite should be called "descriptions" instead of "specs?" What do you guys think? Is it useful to draw a line and say that stories are authoritative and specs aren't? Do you think it becomes less crucial to use object-level specs to enable refactoring, and instead lean on stories more? Pat _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
