• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
atul khot
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
John Smart
Author
Ranch Hand
Posts: 43
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 http://thucydides.info 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
Posts: 814
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?

Burk
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic