Le 21/04/2015 13:44, Sean P. DeNigris a écrit :
Miguel Moquillon wrote
BDD and TDD stands for different purposes with different actors...
While that's unfortunately often true in practice, there is no difference
philosophically. [T|B]DD "done right" always focuses on the user.
[...]
The "In order to..." that you're describing is the outer, high-level
acceptance test that in Ruby for example might be written with Cucumber. But
once one has a failing acceptance test, the next step in BDD is to drop down
into e.g. RSpec and write something a lot closer to a unit test, often
mocking out collaborators to drive creation of an API.
In summary, the intent of BDD is to be "TDD Done Right".
I don't agreed with your assumption: there is a difference
philosophically both in theory and in practice.
The word 'Test' in TDD doesn't mean its purpose is to test; it is a
misconception. In fact TDD is a method for developers to focus on the
design of their code by avoiding over-designing.
In other side, BDD stands for test, more exactly functional testing. It
is a safety belt to
avoid both functional regressions and to ensure the written code is
valid according to
the requirements.
So, when a functional test failed, the next step in BDD is to pass the
control to the developer to fix the issue whatever
its method (BDD don't cover this level).
They are not related but, as you wrote in your example with Ruby, they
can be used both in a project, at a different level. BDD doesn't imply
TDD but yes, in practice, they are often used in conjunction.
Now, some tools were inspired by BDD to provide the developers a better
way to express unit tests (RSpec for example), to be more focused on the
design, but they are in fact more related to TDD than BDD. Don't
confound the approach with the tools.
There is no
inherent conflict, and no specific tools are technically required. Although,
since as McLuhan suggested, we become our tools, so obviously the proper
tools may be decisive, especially when first learning.
There is no conflicts between TDD and BDD because they are not related
and they are not concurrent.
In fact they can be used both but at different level. The same with the
tools.
Beside that, I have a principle: don't learn an approach through a tool.
But use a tool
to facilitate the application of the approach. And as you wrote, indeed,
the proper tool is important.
Miguel Moquillon
