BDD and state
So client worked has kept me too busy to write up the second part of my "mocking":http://blog.new-bamboo.co.uk/2007/2/25/defining-interfaces-through-mocking tutorial. Part two is coming along nicely... Honest guv'nor and describes some advanced mocking strategies but it's taking a bit longer to write than I anticipated. In the meantime I'd like to explain a little more about behavioral driven design. As there is one particular thing I find I'm constantly asked with regards to BDD and mocking and it's driving me nuts explaining it all the time, so listen up BDD nay sayers.
With BDD you're interested in the behavior of the object you're testing.. Simple duh! OK so I've just given you the Zen master says little but explains a lot explanation, not very helpful I now. Anyway, objects in a system never work in solitary at least in any sort of semi-complex system Of course you could cheat and do what one supposed "Sun":http://www.sun.com certified engineer I interviewed once did and write a whole forum in a monolith of a class, but that's another story and it's wrong for me to mock the man like this (did you see the pun! Mock! Ha! Ah, stop throwing the tomatoes!).
Now that I've managed to totally side track this conversation I'll get us back onto topic. The other entities that an objects interacts with are called collaborators and with BDD we're interested in how our objects interact with each other via their interfaces and verifying these interactions. The way we do this in BDD is by the use of mock objects. With a mock object you can not only stub out methods but also attach assertions to verify behavior of the object with it's collaborator. And this is what we're interested in, behaviour not state.
We're not interested in verifying the return value i.e the collaborators state. This is actually something that shocks quite a few Rails developers who are entrenched in their world of fixtures and testing concrete instances. Sure, I'm not saying that I never instantiate a concrete collaborator and use it in memory but I'm very rarely interested in state especially in my unit tests and the Rails 'functional' tests.
The point at which I get interested in state usually occurs around the point of my integration tests and end to end tests. Being interested in behavior rather than state can be quite a big mind shift for a lot of developers but if you give it a try I promise that you'll find your path to testing will be a more enjoyable one.