The point about not changing the state in the specify block is interesting – I think this is where a three-level given-when-then approach (à la Dan North) might be better than rspec’s context-specify model.

What I do is use the setup block to set up the state of whatever I’m testing, and my specify blocks to confirm the state is as expected. I aim not to change the state in any way in the specify blocks, and also try to keep my specify blocks to a single line of code.

So in the example above I’d assign to @user.attributes inside the setup block, and then I’d have two specify blocks: one to check to make sure its not valid, and one to test the error message.

Actually I’d probably have one more specify block just to make sure the number of error messages is equal to 1, which alerts me if other errors creep in unexpectedly.

It probably goes without saying that before all this I’d probably have another context block that assigns all the valid_user_attributes and specifies that @user.should_be_valid.

Yeah its a bit more verbose than what you’re showing above, but it really is much easier to pinpoint where the problem is when stuff goes wrong. If you’re using Textmate and folding, you can just minimize finished contexts and specifications, so it really doesn’t take up that much visual space on the screen.