File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Design and the fly likes Does BDD span/replace existing layers of testing (unit/integration/acceptance)? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Engineering » Design
Bookmark "Does BDD span/replace existing layers of testing (unit/integration/acceptance)?" Watch "Does BDD span/replace existing layers of testing (unit/integration/acceptance)?" New topic

Does BDD span/replace existing layers of testing (unit/integration/acceptance)?

atul khot
Ranch Hand

Joined: Jul 24, 2008
Posts: 64
Hi John,
I develop java apps in Spring/Hibernate. Off late have started developing using Play framework too...
In Spring we write integration tests and unit tests - and selenium based acceptance tests...

How would writing an integration test get changed if I shift to BDD?
Meaning would I write additional tests - or replace the integration tests with something BDD specific?

--- cheerio atul

--cheerio atul
John Smart
Ranch Hand

Joined: Aug 06, 2013
Posts: 43
In general BDD works at two layers: high level acceptance tests and TDD-style unit tests. BDD tools like JBehave work very nicely with Selenium for web tests, as they can make the tests more focused on the business requirements, so that they can also act as living documentation (see and the sample reports on this site for an example of this approach).

When you do BDD at the coding level, you use a top-down approach where you start with the UI and work down, discovering what controllers you need, what your controllers need to do, what services they need, and so forth. At each level, you isolate the next level down using mocks, which lets you discover and define what you need from the next layer down without having to implement it yet. You would also typically have a few integration tests to check the database configuration and the Spring wiring, but using BDD at the coding level and automated acceptance criteria, I find you need a lot fewer integration tests than you might think. Integration tests should only really be used to test interactions with external layers (databases...) and configuration, not components between themselves. Integration tests to test interactions between multiple components (e.g an integration test for a controller that goes all the way to the database) are generally slow, hard to setup and provide poor coverage (you cannot write enough integration tests to check every combination of activities between the components). This is why BDD encourages the use of mocks to describe the interaction between components.
Burk Hufnagel
Ranch Hand

Joined: Oct 01, 2001
Posts: 814
So starting from the UI and working down, you're writing mocks for the level below the level you're currently testing? That sounds pretty cool.

It means you can delay design decisions until you actually need to make them -- and when you do make them, not only do you have a lot of information about *how* the things you're designing are expected to be used, you've got automated tests in place to let you know that what you've built is behaving as expected. What more could we want?


SCJP, SCJD, SCEA 5 "Any sufficiently analyzed magic is indistinguishable from science!" Agatha Heterodyne (Girl Genius)
I agree. Here's the link:
subject: Does BDD span/replace existing layers of testing (unit/integration/acceptance)?
It's not a secret anymore!