3 ms·

TDD was later given the name Behavior Driven Development (before being usurped by the likes of Cucumber, Gerkhin) in an attempt to avoid this confusion. TDD adv

TDD was later given the name Behavior Driven Development (before being usurped by the likes of Cucumber, Gerkhin) in an attempt to avoid this confusion. TDD advocates that you test that the client library does what its public interface claims it does – its behavior, not how it is implemented under the hood. The wire protocol is almost irrelevant. The tests should hold true even when the wire protocol is replaced with another protocol.

WolfOliver 3y ago
Do you have any references that BDD was used as a term before Cucumber?
- voiceofunreason 3y ago
  Search for the writings of Dan North, and don't forget that in the English alphabet, "Behaviour" is spelled with a "U". Very roughly, Cucumber framework appears in late 2008? Whereas BDD first appears in the TDD community no later than December 2005. Ex: here Dave Astels references a BDD talk he presented in 2005-09: https://web.archive.org/web/20051212160347/http://blog.daveastels.com/?p=53 https://web.archive.org/web/20051212160347/http://blog.davea...
rileymat2 3y ago
I suspect it goes deeper than that, which is some of the confusion. If you have multiple layers/parts some will treat each part as an independent library to be used; Implementation details of one level are depending on public interfaces of the next level.
voiceofunreason 3y ago
That's not quite right, historically. Behavior Driven Development began as a re-languaging of TDD: "The developers were much more receptive to TDD when I stopped talking about testing." -- Dan North. BDD diverged from TDD fairly early, after some insights by Chris Matts. As for TDD advocating tests of the public interface... that seems to me to have been more aspirational than factual. The tests in TDD are written by developers for developers, and as such tend to be a bit more white/clear box than pure interface testing would suggest. In the edge cases where everything you need for testing is exposed via the "public" interface, these are equivalent, of course, but there are tradeoffs to be considered when the information you want when running isolated experiments on an implementation isn't part of the contract that you want to be supporting indefinitely.

WolfOliver 3y ago

Do you have any references that BDD was used as a term before Cucumber?

voiceofunreason 3y ago
Search for the writings of Dan North, and don't forget that in the English alphabet, "Behaviour" is spelled with a "U". Very roughly, Cucumber framework appears in late 2008? Whereas BDD first appears in the TDD community no later than December 2005. Ex: here Dave Astels references a BDD talk he presented in 2005-09: https://web.archive.org/web/20051212160347/http://blog.daveastels.com/?p=53 https://web.archive.org/web/20051212160347/http://blog.davea...

rileymat2 3y ago

I suspect it goes deeper than that, which is some of the confusion. If you have multiple layers/parts some will treat each part as an independent library to be used; Implementation details of one level are depending on public interfaces of the next level.

voiceofunreason 3y ago

That's not quite right, historically. Behavior Driven Development began as a re-languaging of TDD: "The developers were much more receptive to TDD when I stopped talking about testing." -- Dan North. BDD diverged from TDD fairly early, after some insights by Chris Matts. As for TDD advocating tests of the public interface... that seems to me to have been more aspirational than factual. The tests in TDD are written by developers for developers, and as such tend to be a bit more white/clear box than pure interface testing would suggest. In the edge cases where everything you need for testing is exposed via the "public" interface, these are equivalent, of course, but there are tradeoffs to be considered when the information you want when running isolated experiments on an implementation isn't part of the contract that you want to be supporting indefinitely.