Mahtab Alam wrote:What is meant by behavior driven development ?
As I understand it, BDD means understanding how the program is supposed to behave (for example, an ATM should not allow me to withdraw more money than I have in my account), then writing the code to verify that the program matches that behavior. You can also use the high-level behavior test/description to drive the low level unit tests needed for the application.
So, looking at the behavior in the ATM example, you might realize that you need a class representing your bank account and that a withdraw request for more money than the account balance should fail. However, it might also get you thinking that before you can make this behavior work, you need to get the account information and that you should only retrieve the info for the account holder, or a bank employee with the right permissions.
It's a way to help tease out requirements that might not be specified because they're obvious to the people writing requirements, so they don't bother documenting them.
sadly, there is no simple answer to this questions. Behaviour Driven Development means different things to different people. I dedicated a whole chapter of my book to this question. That said - Burk's answer is really good. It covers the very essence of BDD.
BDD means understanding how the program is supposed to behave
That is something we all can agree on - I think. The opinions, on how behavior is going to be verified ... differs. At least, I would say the GUI is not very important. We usually have some end-to-end acceptance tests to verify system integration. Most business logic, on the other hand, is specified directly with the domain models. Writing too much GUI specs tend to become very brittle and hard to maintain ... very fast and early in the project.
hopefully this makes it a bit more clear,
Marco Emrich wrote:That said - Burk's answer is really good. It covers the very essence of BDD.
Thank you, Marco.
Marco Emrich wrote:At least, I would say the GUI is not very important. We usually have some end-to-end acceptance tests to verify system integration. Most business logic, on the other hand, is specified directly with the domain models. Writing too much GUI specs tend to become very brittle and hard to maintain ... very fast and early in the project.
I partially agree with you about trying to test GUIs, but I think it depends on what kind of testing you're trying to do. While testing what's on a page may make sense, testing how it looks to the user may not.
About a year ago, I started playing with BDD and used tools like Geb and Selenium 2 to drive a Web-based application through about a dozen steps in order to verify that it matched the expected behavior for a couple of work flows. I focused on what controls should be enabled or disabled, which page it went to based on input from a form, and whether expected error messages were displayed or not.
In order to make things less brittle, I did things like having the code pull the error messages from the same source that the production code used. In one case it was a matter of making a hard-coded message into a publicly available String, and comparing it with what was displayed on the Web page.
The nice thing about writing those tests is that I was able to show that the system worked as expected and, when changes were made to the production code, we knew right away that everything still worked - or where it was broken and what the expected result should have been.
Sorry for the long post, I just wanted to point out that it is possible to test GUIs without creating brittle test code that has to be tweaked every time someone makes a change to the production code.
Marco Emrich wrote:Sorry, for my black/white statement. There are of course, situations and projects where building specs on top of the gui is worthwhile. I just wouldn't want to give the impression that BDD is mainly about GUI-testing.
No need for apologies. I guess I just always though of BDD as being focused on the system's behavior - which I think of as meaning what the end user sees. If the application is a web service then I'd test the results returned for various inputs, and if it's something with a GUI then I'd expect to test what's being displayed on the screen.
I hadn't considered using BDD to just test the business logic because there could be problems between the business logic and presentation layers, so even if the lower level is correct, the system might not be showing the user what they expected to see,
Does that seem reasonable?
Burk Hufnagel wrote:Does that seem reasonable?
Sure, it's very reasonable.
I think it's a balance thing. If you are don't have maintainability worries with you high-level specs and they execute fast enough - I see no harm doing it this way.
In case you are interested in our (company) approach: It's threefold:
1. We have some end-to-end specs, to mitigate the risks of the integration issues, you mentioned. But we want to keep the number of them low, because we have maintainability issues
2. We have high-level (acceptance) specs, directly on the business logic (domain model)
3. We have tons of low-level (unit) specs on business logic, but also on gui behavior (for some widgets). This means we have some gui specs, but they verify the gui behaviour only and are completely decoupled from business logic.
This works well for our current project. Each project (also team and environment) has of course different needs.