I have no experience neither in TDD nor in BDD. Yes I've created unit tests for existing code a lot, but it's not relevant here. Also I cann't use TDD/BDD at my job but want to try in some hobby project.
I am not sure if I currently grasped the difference between TDD and BDD correctly. For now I just see BDD as evolved TDD with the most destinctive feature being the ability to work on higher level of abstraction (user stories) then TDD. In TDD you basically get same user stories but they are not as explicit as in BDD. Is it correct?
In terms of tools, assuming that statements above are correct, for TDD I should use something like TestNG or JUnit, and for BDD I'll benefit from tools like JBehave.
Now the question is should I first start with TestNG and TDD and only after some succesfull experience with it migrate to JBehave and BDD? Or this is just waste of time and there are no reasons at all preventing me from trying to use Jbehave and BDD from the very beginning?
UPDATE:
After receiving two great answers on my question, and spending some time on additional reading on the topic, I couldn't help myself not to add link to a great article I found. It just repeats same ideas as in two answers to this question below, but maybe with more details. My favorite part of the article:
The best way to do that is to leverage BDD and TDD. Here is an approach: 1. Write requirements as user stories using the BDD grammar/structure. Do this collaboratively with the key stakeholders. 2. Enter the User Stories (feature + scenarios) in a BDD tool. 3. Write code to map the User Stories to tests. 4. Write production code using TDD to make the tests pass.As you can see, BDD is not just TDD done right. You could use just the vocabulary of BDD to improve TDD but that would be like using only some of the benefits that BDD has to offer us. When we use the the strengths of both these techniques we will have “Software that matters” along with “Software that works”.
BDD concentrates on testing the functionality of the app, and ensuring that it meets the stated acceptance criteria of the application as described in the user story.
TDD tends to concentrate on the lower-level code, testing on a per-class basis rather than on a per-functional-unit basis.
If you have a good idea of what you want to achieve in the user story - enough to enumerate a list of things the feature should & shouldn't do - you're in a good position to start BDD. You can write a BDD feature file from that list, and doing this before writing a scrap of code will allow you think about the feature and crystallise your thinking on it. This will help you write more concise correct code.
I would suggest looking at Cucumber-JVM as your tool for implementing the BDD tests, but I'm told JBehave is functionally similar.
Finally, to me BDD and TDD are techniques that compliment each other, not compete - doing the BDD beforehand makes it easier to think about what is required, which makes it easier to think of what low-level functionality is required, which in turn makes it easier to write your unit tests up front. Once the code is written, you then have a suite of tests allowing you to prove the app meets the acceptance criteria.
The way I do BDD is this:
1) Examine the user story for User-Acceptance Criteria
2) Write a feature file (English) containing test scenarios to test each of these conditions.
3) Implement the feature
4) Use Cucumber/JBehave to programmatically implement the tests from the feature file
5) Ensure all the tests pass
We then maintain a library of these tests, and run them as part of our Continuous Integration
A feature file contains instructions in a specific wording, such as:
Given a user goes to our app
When the user clicks on the search link
Then the search window opens
And the user enters XXX in the search box
And the user presses enter
The search results are displayed