DBC and TDD/BDD are clearly closely related ways of thinking, but I think they have slightly different advantages and disadvantages.
They both tell you where the problem is when something goes wrong (but DBC is better at that).
They both provide documentation about how to call things (but BDD is better at that).
They both help you think out the requirements for what the code you're writing has to do (but BDD is better at that).
They both make your software more robust (but DBC is better at that, because it checks real values instead of fake ones).
They both reduce the effort of refactoring your software (but BDD is better at that).
They both reduce the time from when you write a bug to when you find it (although arguably BDD is better at that, because you don't have to test anything manually in order to make things blow up).
Unfortunately my experience with DBC (even in the informal sense you describe) is minimal. Anyone with experience with both who can confirm or deny?
no subject
They both tell you where the problem is when something goes wrong (but DBC is better at that).
They both provide documentation about how to call things (but BDD is better at that).
They both help you think out the requirements for what the code you're writing has to do (but BDD is better at that).
They both make your software more robust (but DBC is better at that, because it checks real values instead of fake ones).
They both reduce the effort of refactoring your software (but BDD is better at that).
They both reduce the time from when you write a bug to when you find it (although arguably BDD is better at that, because you don't have to test anything manually in order to make things blow up).
Unfortunately my experience with DBC (even in the informal sense you describe) is minimal. Anyone with experience with both who can confirm or deny?