JBehave philosophy
The philosophy that drove the development of JBehave is the same that underlies BDD, i.e. to facilitate the communication of business requirements or behaviours between the stakeholders and the development team, and to allow these behaviours to be verified in an automated way using continuous integration.
The emphasis here is on communication.
BDD vs TDD
It is important to keep BDD distinct from TDD. These two practices are equally important but address different concerns and should be complementary in best development practices.
BDD is concerned primarily with the specification of the behaviour of the system under test as a whole, thus is particularly suited for acceptance and regression testing. TDD is concerned primarily with the testing of a component as a unit, in isolation from other dependencies, which are typically mocked or stubbed.
BDD should talk the language of the business domain and not the language of the development technology, which on the other hand is “spoken” by TDD.
Suggested uses
JBehave scenarios are best suited to capture and express the requirements of an Agile iteration. They should be written and agreed in the iteration planning meeting. They specify the definition of done. They can be written either by the development team, e.g. by a business analyst, or can also be written the stakeholders themselves.
As iteration follows iteration, the scenarios also provide an invaluable regression test suite. As such they need evolve with the code itself, to reflect changes in the expected behaviour from one iteration to the next.
The code to satisfy the scenarios need not be implemented immediately, but the textual scenarios should be inserted from the start into your build system. By default, JBehave is tolerant of scenarios with unmatched step methods, simply marking them as pending and highlighting the non-completeness of the scenario (e.g. outputting the scenario to console). It does not, though, make the build fail. This behaviour is nonetheless configurable, and developers can turn on a more strict pending error strategy which would break the build if any pending steps are found.