Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Re: Facts for incremental value of BDD? (Beyond TDD)

Expand Messages
  • Charlie Poole
    It s possible to think of ATDD as a subset of TDD and many people do. I prefer to keep the notion that TDD is about low-level tests focused on accomplishing
    Message 1 of 234 , May 8 8:24 AM
      It's possible to think of ATDD as a subset of TDD and many people do.

      I prefer to keep the notion that TDD is about low-level tests focused on
      accomplishing the intention of the programmer. Customer tests, obviously,
      are about the intention of the customer.

      I recognize that it's reasonable to use these terms in many ways - and
      many people have different definitions if you dig deeper. For me, this
      distinction is such an important one that I prefer to consider Customer
      tests as truly distinct.

      To my mind, Dan North style BDD is simply TDD using different words -
      it's not even a subset. I happen to think the focus on words is a little
      narrow, but that's just me.

      The style of BDD that merges developer and customer testing is not
      something I like at all, for the same reasons given above.

      We used to have an acronym that subsumed all these different things.

      Hint: think of two letters, the first is X, the second P. :-)

      Charlie

      On Tue, May 8, 2012 at 7:43 AM, M. Manca <m.manca@...>wrote:

      > **
      >
      >
      > Il 08/05/2012 13:50, RonJeffries ha scritto:
      > Ron,
      > a little premise: I ask you the questions because I am not able to
      > define a well defined border between TDD, ATDD and BDD, actually I think
      > at ATDD and BDD as childrens of TDD or as members of the TDD set.
      >
      > >
      > >
      > >
      > > On May 8, 2012, at 7:00 AM, M. Manca wrote:
      > >
      > > > do you think that ATDD and BDD are different answers to
      > > > simplify/discipline TDD learning?
      > >
      > > TDD is not ATDD and is not the high-level BDD. TDD is a software
      > > design technique driven by writing "tests".
      > >
      > > ATDD is analogously named, and represents the idea of using concrete
      > > acceptance tests to express the desired product.
      > >
      > > Dan North BDD had the same goals as TDD, and as I understand it, was
      > > trying to focus on low-level behavior because Dan noticed that some
      > > learners were not doing TDD well. I do not know whether it helps or
      > > not, since I am not a learner.
      > >
      > >
      > > I do not understand Matts / Keogh BDD well enough to speak even that
      > > definitively, but it seems to me to include more analysis thinking,
      > > bound up with concrete examples.
      > >
      > Also I have some problems to understand what they think and what is the
      > key point of feature injection that can help me.
      >
      > >
      > >
      > > I believe they are all the same basic idea, that of using concrete
      > > tests to "drive out" what one is doing. Their descriptions focus on
      > > different details of the same situation. I see no reason to
      > > distinguish them if one knows none of them. Instead, one ought to get
      > > started.
      > >
      > > > What between BDD and ATDD fits better to translate a requirement to an
      > > > executable requirement in your opinion?
      > >
      > > I see no significant difference. An expert will move among the
      > > techniques without noticing boundaries.
      > >
      > > > I know that there were some improvements in the ideas that led to
      > > > realize JBehave, RBehave and Cucumber giving more emphasis to the
      > > > natural language used to describe the requirements.
      > >
      > > Yes. These are tools, not ideas. Natural language is not a good
      > > description of any of them. Anyone who knows any way to express
      > > requirements in examples can learn to use any of these in a matter of
      > > hours or at most a couple of days.
      > >
      > I wanted to say that all of them have the common idea to translate a
      > requirement in an executable requirement (using a different syntax) with
      > the idea to use a natural language form to help users/stakeholders.
      >
      > >
      > >
      > > > In my opinion the idea behind BDD is a more explicit form of TDD, seems
      > > > a simpler way to follow. Of course using properly TDD I can obtain same
      > > > results as following BDD with some little differences.
      > >
      > > I would challenge you to write two short paragraphs saying what BDD
      > > and TDD each is, clearly bringing out the similarities and
      > > differences. I think you'll find it quite challenging.
      > >
      > Yes, there are very little differences. To me the difference is not on
      > the concepts but in the practical realization. Following BDD a user
      > story has a title and a description that should be in the form "As a-I
      > want-so". Then every user story has one or more scenarios that have a
      > title and a description in the form "Given-Then-When" as specified by
      > gherkin syntax. This is the main difference I find: BDD provide a syntax
      > to drive user stories and executable test writing. I think at this as a
      > template.
      >
      > >
      > >
      > > Ron Jeffries
      > > www.XProgramming.com
      > > I know we always like to say it'll be easier to do it now than it
      > > will be to do it later. Not likely. I plan to be smarter later than
      > > I am now, so I think it'll be just as easy later, maybe even easier.
      > > Why pay now when we can pay later?
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • MarvinToll.com
      I remember anxiously anticipating some capability in COBOL 85 when working for EDS on the General Motors account... however, that is as memorable at the moment
      Message 234 of 234 , May 19 9:41 AM
        I remember anxiously anticipating some capability in COBOL 85 when working for EDS on the General Motors account... however, that is as memorable at the moment as yesterday's breakfast.

        More to the point, I am anxiously awaiting select functional programming capabilities being introduced in Java and am happy to observe Oracle moving the platform forward... at least through 2021.

        As a side note, I've been appreciative of Oracle's handling of the challenging task so far... and am (at the moment) optimistic that both multi-core and functional capabilities being supported are sufficient for potentially all of my current customer's anticipated needs.

        _Marvin
        http://PatternEnabled.com

        --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
        >
        > And how many programmers using a COBOL 85 compiler are writing code that is much different than just COBOL 64?
        >
        > My observation has been "not many."
        >
        > (based on, admittedly, relatively few data points)
        >
        > --- "MarvinToll.com" <MarvinToll@> wrote:
        > > One. That OO COBOL was not really a maturation of the original
        > > 1959 design intent...
        > >
        > > Two. That OO COBOL was not durably embraced by the global IT
        > > community...
        > >
        > > Three. The existence of OO COBOL does not automatically
        > > constitute a "maturing" of the language. :-)
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.