BDD adds a cycle around the TDD cycle.
So you start with a behaviour and let that drive your tests, then let the tests drive the development. Ideally, BDD is driven by some kind of acceptance test, but that's not 100% necessary. As long as you have the expected behaviour defined, you're ok.
So, let's say that you're writing a Login Page.
Start with the happy path:
Given that I am on the login page
When I enter valid details
Then I should be logged into the site
And shown my default page
This Given-And-When-And-Then-And syntax is common in behaviour-driven development. One of the advantages of it is that it can be read (and, with training, written) by non-developers -- that is, your stakeholders can view the list of behaviours you have defined for successful completion of a task and see if it matches their expectations long before you release an incomplete product.
There is a scripting language, known as Gherkin, which looks a lot like the above and allows you to write test code behind the clauses in these behaviours. You should look for a Gherkin-based translator for your usual development framework. That's out of the scope of this answer.
Anyway, back to the behaviour. Your current application doesn't do this yet (if it does then why is someone requesting a change?), so you're failing this test, whether you're using a test runner or simply testing manually.
So now it's time to switch to the TDD cycle to provide that functionality.
Whether you're writing BDD or not, your tests should be named to a common syntax. One of the most common is the "should" syntax you described.
Write a test: ShouldAcceptValidDetails. Go through the Red-Green-Refactor cycle until you're happy with it. Do we now pass the behaviour test? If not, write another test: ShouldRedirectToUserDefaultPage. Red-Green-Refactor til you're happy. Wash, rinse, repeat until you fulfil the criteria set out in the behaviour.
And then we move on to the next behaviour.
Given that I am on the login page
When I enter an incorrect password
Then I should be returned to the login page
And shown the error "Incorrect Password"
Now you shouldn't have preempted this to pass your earlier behaviour. You should fail this test at this point. So drop back down to your TDD cycle.
And so on until you have your page.
Highly recommend The Rspec Book for learning more about BDD and TDD, even if you're not a Ruby developer.
The prerequisites are the "Given" part of the equation. This should preferably access the database directly and create the objects you need. So for your case:
Given user "whatf" exists
And user "whatf" has 3 blog posts
When "whatf" logs in
Then he should be shown a list of all his posts
Now, step user "whatf" exists creates a user in the database (we name the user so that we can have a specific definition of the user behind-the-scenes, such that you don't have to say user exists with admin rights and pink theme and password "s3cret" ... over and over).
Step user "whatf" has 3 blog posts creates three blog posts in the database, against that new user. You can be more or less specific here, if you choose. More specific gives you flexibility, less specific gives you more reusable steps.
Step "whatf" logs in should be the first time you use Selenium, to launch the browser and log the user in.
Then, in the confirmation step, you also use Selenium to check that the user is shown a list of all his posts in the response.
Also note that the difference between TDD and BDD is really dictionary. BDD encourages a more behaviour-driven language for your tests. But those tests can still be unit tests. Or they can be acceptance tests (ATDD).
But the difference between what we call a unit-test framework (eg. xUnit) and what we call a BDD framework (eg. Cucumber) is much bigger. A BDD framework is much more accurately called an acceptance-test framework, if we're to compare it to a unit-test framework. There are also unit-test frameworks that are designed with BDD in mind -- we call them context/specification test frameworks (as opposed to arrange/act/assert).
Best Answer
Behavior Driven Development and Test Driven Development are complimentary, but not a replacement for each other.
How the application "behaves" is described in Acceptance Tests, which according to BDD would be the Features and Scenarios written in Cucumber.
The nitty gritty details of how each small component works are described in Unit Tests. The outcomes of the Unit Tests support the Scenarios you write in Cucumber.
Imagine the process for building a car.
First, the product team comes up with their ideas, and eventually boil them down to usage scenarios:
I know this scenario sounds a bit silly, but it is a very high level, product and end user focused requirement. Just opening the door, turning the key and starting the engine involves a LOT of different components working together. This one test is not enough to make sure the vehicle works properly. You need to test the starter, the battery, the alternator, key, ignition switch --- and the list goes on --- just to get into the car and start it. Each of those components need their own tests.
The scenario above is a "Big Picture" test. Each component of the vehicle needs "Small Picture" tests to make sure they function properly within the whole.
Building and testing software is the same in many respects. You design from top down, then build from bottom up. Why have a door that lifts up if you can't even start the engine? Why have a starter if you have no battery?
Your product team will come up with the Acceptance Tests and flesh them out in Cucumber. This gives you the "Big Picture". Now it's up to the engineering team to design the proper components, and how they interact, then test each one separately --- these are your Unit Tests.
Once the Unit Tests are passing, start implementing the Cucumber scenarios. Once those are passing, you have delivered what the product team has asked.