Tests vs. Specifications
November 11, 2007 – 11:40 pmThis is a brief extract from the talk I gave at Rubyconf - I wanted to call it out specifically, because it generated some good discussion in Charlotte, and I think it’s an interesting topic.
RSpec is (in part) motivated by linguistic theory; in particular, the idea that language influences the way people think (this is the weak form of the Sapir-Whorf hypothesis). The relevant application of that theory is this: a test is something that happens after an event. You can’t test something that does not yet exist - in school, you learn something, and then you are tested. Test-driven development, then, is almost an oxymoron - and this is a harmful way of speaking. Because language influences the way we think, if we talk about tests we’re biasing ourselves to think about them coming after the code is written.
BDD and RSpec deal with this by changing the language. Instead of tests, they deal with specifications. Specifications come before an event - you specify something, it happens, and you evaluate the event against the spec. By switching the language, you’ve set up the appropriate bias - you’re thinking about specifying the behavior of the code before you write it. By changing the language, then, you’re getting developers to lean in the direction of best practices.
Of course, many of us (me included) may argue that we can do TDD successfully. While other people might be manipulated by using “test” instead of “specification,” we are bright enough to do what we know to be best regardless of how we talk about it.
While that may be true, it doesn’t refute the base argument. Linguistic relativism is not linguistic determinism; it is certainly possible to think and act in opposition to the language being used. Nevertheless, you’re thinking and acting in opposition to the language, which means that at best you’re wasting cognitive energy. Why not just use the language that actually implies the thoughts and behaviors you want to have?
2 Responses to “Tests vs. Specifications”
This is the right approach but still has a long way to go. Right now we sit with customers and write down the requirments from which a design and spec are derived from which the tests can be written (perhaps in a DSL like RSpec). Why the layers? At each layer we lose detail or make incorrect assumptions (and with each step in the process we get further from the customer).
Development tools already have the ability to go from model to code and back again. Test tools need the same capability. To go from the written spec to the DSL and back again. One data set - multiple representations.
By Robert on Nov 12, 2007
The language difference was very important for me in resisting the urge not to “test” very important things like validation. Back in my Test::Unit days I’d use the argument that it was pointless since I was just testing ActiveRecord functionality that already has tests elsewhere (in rails core). Now though, with rspec, I’m thinking the way I should be: that validations are part of my model’s behavior, and should have specifications to enforce that behavior.
That’s just one example, rspec has really changed the way I write code, and I love it pretty hard.
By Justin on Dec 7, 2007