Nobody in the world will agree with this, until I finish.
One spec per file, while developing.
Consider this problem:
One major problem with automated test suites is that they function both as development tools and as traditional software quality testing. Your unit test suite turns into a regression test suite when it matures, i.e., once you're done developing and you've got a piece of code which works. But that's not how it should be. You've got two types of tests that need to exist, and a twisted mutant hybrid which serves both roles. It is a thing which should not be. An abomination. A monstrosity. A spork.
Separate your development specs from your de facto regression-suite specs. When you're doing BDD, you want those things to run as fast as possible. Any delay gets you out of the zone. Specs should run as fast as reflex.
Once you've got your code doing what you wanted to do, copy/paste your new specs into the main spec file for whatever class you're monkeying with, and make sure it still works. Run the real spec file for the class, with all the specs. Once that is done, run all your specs.
The major win of BDD is the incredible speed and flow. Don't deprive yourself of that experience. It's what makes coding worth doing.