Thanks for the response. I was under the impression that BDD was an evolution of TDD rather than something which would work alongside it.
With TDD I am writing tests first to code behavioural aspects but I am coding with low level aspects in mind such as object collaboration, but with BDD things are on a much higher level so it seems to me that BDD is not an evolution of TDD if I still need to test the lower stuff. I am imagining that I need to use BDD to describe the high level behaviour but also having to do TDD right alongside it to design and develop the code which gets plugged into the BDD scenarios. This seems like boiler plate hell to me and I can see the boiler plate stuff growing massivly compared to the production code. Chris > If I might butt in here.... > > Chris, are you familiar with the V-model? > (http://www.google.co.uk/search?q=v+model+of+software+testing) > > In that you have BDD at the top end of the chart, where you have non > technical stakeholders, with engineers and TDD at the bottom. If you look > at classic waterfall then activity goes from left to right, requirements, > design, code, unit test, integration and system test, acceptance test and > ship. > > BDD and TDD allow you to engage the non techies at a lower level, or even > let them drive your development if for example they can write requirements > in the form of scenarios. > > As I see it, The annotations in jBehave let you link scenarios to test > code (which might well be unit test code), and code coverage allows you to > tie test code back to source. This is close to requirements traceability, > where you can see the code exercised by a requirement (scenario). > > BDD TDD > Scenario<------annotations---------->unit tests-----code > coverage------>source > > You can even feed back on the scenarios, because if they don't match the > code behaviour, then you have something precise to talk to your > stakeholders about, in language they should understand (cos they wrote it > initially). > > The other thing I've often found is that you end up writing good code that > works but it doesn't do quite what the customer wanted (CMM's verification > vs validation). BDD I've found helps non techies express themselves more > clearly and give you good and testable requirements. > > regards > > Rob > > > > *********************************************************************************** > This e-mail and attachments are intended for the above name only and may > be confidential. If they have come to you in error, you must take no > action based on them, nor must copy or show them to anyone; please reply > to this e-mail and report the error. > Security warning: Please note that this e-mail has been created in the > knowledge that the internet is not a one hundred percent secure > communication medium. We advise that you understand and observe this lack > of security when e-mailing us. > Virus: Although we have taken steps to ensure that this e-mail and > attachments are free from any virus, we advise that in keeping with good > practice the recipient should ensure they are actually virus free. > If you have received this e-mail in error please notify: > [email protected] > YELL ADWORKS is a business name of YELL MEDIAWORKS LIMITED > Registered Office: Queens Walk, Oxford road, Reading, Berkshire, England, > RG1 7PT. > Registered in England and Wales, registered number 06649631 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
