Historically, BDD evolved out of attempts to improve TDD (sometimes you'll hear things like "BDD is TDD done right"), but nowadays I see it as something complementary and orthogonal to TDD (where by TDD one assumes unit-level testing).
I agree with your interpretation of TDD as lower-level testing and BDD as higher-level. I don't quite agree with Rob's diagram: scenarios --> unit-tests True BDD scenarios may be run "technically" via JUnit but that does not make them unit-tests, just like one can run integration tests via JUnit. The nature of testing has more to do with the objective it has and the elements it interacts with. On 26/08/2010 12:15, [email protected] wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
