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).
It's comparing oranges and apples.
Integration tests, acceptance tests, unit tests, behaviour tests - they are all tests and they will all help you improve your code but they are also quite different.
I'm going to go over each of the different tests in my opinion and hopefully explain why you need a blend of all of them:
Integration tests:
Simply, test that different component parts of your system integrate correctly - for example - maybe you simulate a web service request and check that the result comes back. I would generally use real (ish) static data and mocked dependencies to ensure that it can be consistently verified.
Acceptance tests:
An acceptance test should directly correlate to a business use case. It can be huge ("trades are submitted correctly") or tiny ("filter successfully filters a list") - it doesn't matter; what matters is that it should be explicitly tied to a specific user requirement. I like to focus on these for test-driven development because it means we have a good reference manual of tests to user stories for dev and qa to verify.
Unit tests:
For small discrete units of functionality that may or may not make up an individual user story by itself - for example, a user story which says that we retrieve all customers when we access a specific web page can be an acceptance test (simulate hitting the web page and checking the response) but may also contain several unit tests (verify that security permissions are checked, verify that the database connection queries correctly, verify that any code limiting the number of results is executed correctly) - these are all "unit tests" that aren't a complete acceptance test.
Behaviour tests:
Define what the flow should be of an application in the case of a specific input. For example, "when connection cannot be established, verify that the system retries the connection." Again, this is unlikely to be a full acceptance test but it still allows you to verify something useful.
These are all in my opinion through much experience of writing tests; I don't like to focus on the textbook approaches - rather, focus on what gives your tests value.
Best Answer
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:
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.
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.