Le 21 avr. 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. But > because of the word "test" in TDD, many tests (including many in our image) > became incomprehensible from a "how do I use this library" POV, tested > internal implementation details, etc. So BDD was invented to make the focus > on behaviors explicit and to guide us all toward best practice. It also > quite nicely unified acceptance testing and unit testing. > > 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.
this one is often called the outside - in loop (ref: http://dannorth.net/whats-in-a-story/). Even is the outside - in loop is not used, I find valuable to encourage people to name (and write) their unit tests in terms of behavior.
smime.p7s
Description: S/MIME cryptographic signature
