How does behaviour drive development?

I’ve only recently started dabbling in BDD using Cucumber and RSpec in Rails applications. It feels quite different to the TDD practices I’ve adopted before in Java, PHP or Ruby.

It feels like I’m starting from the top of the software stack and working down from broad specifications, creating code as I go, rather than up from fine grained models based on specific unit tests. Is this a reductionist approach?

When writing my features and scenarios I’ve noticed a tendency to follow the CRUD acronym common in data access layers: Create Read Update and Delete. The order of these processes is significant and my reasoning goes something like this……

I can’t really expect to read the contents of an entity before I’ve generated the code to create it. Now I’ve created it, I’m not going to try to edit this same entity unless I can actually read it. I can read what I’ve got, but I might want to edit those contents, and delete comes last…… because it just does, I guess the order of “UD” is negotiable, but this way it’s easier to pronounce.

You get the general picture, but this is just the approach I’ve adopted through trial and lots of error. It’s far from perfect, so how do you use behaviour to lead the code?