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.
Do both. Integration tests serve the purpose of checking that two pieces of functionality that should work together do work together. BDD (or any other form of acceptance) tests verify that the user-visible feature works according to the needs of the customer and the business. If the end requirement is that someone can access a website, you must do that with a non-integration test because that's how the user will interact with the system.
All that being said, don't get hung up on terminology. Call the tests whatever you want. At the end of the day the software needs to be tested. You don't get bonus points for testing them with BDD or with functional or unit tests. The only bonus points are whether or not the software is as bug-free as possible.
In a perfect world you would have a huge pile of unit tests that test each unit individually, a smaller set of integration tests that verify the integration of each of those units, and an even smaller set that verifies that the UI is functioning properly and calls the appropriate functions. And, of course, an even smaller set of exploratory tests that let your trained quality analysts use their intuition to find the really deep, gnarly bugs that are hard to catch in an automated fashion.
Best Answer
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:
Now, step
user "whatf" existscreates 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 sayuser exists with admin rights and pink theme and password "s3cret" ...over and over).Step
user "whatf" has 3 blog postscreates 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 inshould 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 postsin 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).