It's the ATDD and
BDD that removes all the bugs - i.e. not "using TDD alone"
. TDD just helps us get there when filling in the very minute gaps that the specs don't directly fill. To us, TDD is "this card shuffler should randomise the order of this pack" whilst BDD and ATDD take care of the "given I've got a pack of cards in a contiguous order, when I shuffle those cards, then those cards should be in a random order." I hope the meaning behind the difference between those statements is clear.
We also advocate CQRS, and Event Sourcing. It is absolutely imperative that everything is broken down to the smallest possible detail with the person(s) who understands what it is that is required - not a BA or Manager, but the actual expert of the domain. No room for "just simple CRUD" at all here. Ergo, there is no way for there to be erroneous input. Must have complete and concise capture of the intent behind an operation. There is no "allow admin to update a user." There is only commands and events for "changing the name of a user because they have married
" or "changing the name of a user because they have divorced
." It's as complex as complex can be, but we must understand it all to develop it. Number of tests is exponential to complexity of software because rule number one of BDD, TDD, CQRS is to eradicate complexity. Complexity is compacted simplicity. Is it complex? Then take smaller bites.
A "Bug" is unintentional behaviour through oversight or mistake when developing. It's very, very difficult (I'm only refraining from using "impossible" due to the uncertainty principle here :p) to do either of those if employing BDD (and employing it "properly".)
4, nearly 5 years bug free on a very large system spanning multiple technologies and platforms; interacting with multiple systems including many 3rd party systems, and used globally by 120,000+ users for real time transportation of pharmaceutical supplies, with 2 teams of 8 developers working full time adding new features, both teams limited to 3 stories in "work in progress". It's not simple software.
Anyway... I hope that isn't too "smug".. I really don't intend it to be, so apologies if it is. I replied to give some light onto what benefits resusability in OOP has, and that, like all things in life, it can be "done badly" and then I saw Benjamin's post and just couldn't resist responding to his misunderstanding(s) but I can see I've upset him and possibly others, so I'll return to lurking again.