Extreme Programming

Theresa Forster | 6 May 2012 11:24

How to do this?

I have a conundrum, I have a VB.NET WCF service I need to recode and clean
up into C#,

I want to drive it out using Agile using just the name of the service and
the existing database at the top and bottom allowing XP and Agile to drive
out the logic in the middle.  

The old system is using CSLA which is mind bogglingly slow. So I need to use
something maybe NHibernate or something. I don't know as I haven't driven it
out yet.

My question is where should I start? What should I do as a test first? The
WCF declaration is fixed for the moment, but we will be adding restful to
the mix going forward. So should I build an adapter pattern behind the WCF
or maybe a Controller Pattern. 

Being new to agile I am not sure which pattern fits here nor where to go
forward, so some suggestions would be really helpful.

Thanks

Theresa 

[Non-text portions of this message have been removed]

headers

Adrian Howard | 6 May 2012 13:40

Re: How to do this?

On 6 May 2012, at 10:24, Theresa Forster wrote:

> I have a conundrum, I have a VB.NET WCF service I need to recode and clean
> up into C#,

Have you looked at the techniques covered in "Working Effectively With Legacy Code" by Michael Feathers
and "Behead Your Legacy Beast" http://mikadomethod.org? Both useful reads.

Cheers,

Adrian
--

-- 
http://quietstars.com     adrianh <at> quietstars.com     twitter.com/adrianh    
t. +44 (0)7752 419080     skype adrianjohnhoward     del.icio.us/adrianh

headers

Theresa Forster | 6 May 2012 14:26

RE: How to do this?

Well that would be nice, but the code is a nightmare, as in including
several subclasses which are worse still (and all over the place with
Business login in every class)

Any refactor would have to be total and across the board otherwise we come
across circular dependancies between the old code and the new C# classes.

So the plan is to rewrite it TDD/BDD using patterns and practices which were
ignored in the original.

At the moment we have 2 endpoints, basic + wshttp bindings with a Service
and an APIservice the latter being the WS and the other being the local
comms to the web app.

This application has links to multiple apps all over the shop so the
interface to the methods cannot change in this iteration neither can the DB
unless it is to improve the way it works.

The starting point for me is theoretically create an adapter pattern just
behind the WCF contracts and have them simply call into the adapter then
drive out the business logic based on the BDD of each call in turn, driving
down to the repository in slices.

I am asking, is this the right way to go or is there a better less painful
way of performing this task - essentially I am building new code based on
Old contract at the WCF end

Theresa

From: extremeprogramming <at> yahoogroups.com

(Continue reading)

headers

RonJeffries | 7 May 2012 00:47

Re: How to do this?

Hi Theresa,

On May 6, 2012, at 8:26 AM, Theresa Forster wrote:

> Well that would be nice, but the code is a nightmare, as in including
> several subclasses which are worse still (and all over the place with
> Business login in every class)
> 
> Any refactor would have to be total and across the board otherwise we come
> across circular dependancies between the old code and the new C# classes.
> 
> So the plan is to rewrite it TDD/BDD using patterns and practices which were
> ignored in the original.

Rewriting is not refactoring. Refactoring is always possible, and always difficult. However, rewrite
projects are also difficult and far from always possible.

I would not recommend rewriting to anyone "offhand", though I can imagine that there might be a situation
where, upon deep study, I would recommend it. It is always tempting at the outset to rewrite, and we imagine
this great result we'll have. The reality generally does not measure up.

You and your people need to decide, of course, and if you decide to go ahead, then TDD/BDD and so on are of
course the way to go.

Are you and your team skilled in those practices? If not, how do you plan to gain the needed skill in time?

Regards,

Ron Jeffries
www.XProgramming.com

(Continue reading)

headers

MarvinToll.com | 7 May 2012 14:15

Re: How to do this?

Ron... I'm not trying to pick a fight on this... it is a legitimate quesiton.

Has anyone made the factual case for BDD... beyond the benefits of TDD?

That is, if one is already practising TDD... what incremental costs/benefits (in quantifiable terms)
could one expect from addding BDD?  [And perhaps, has anyone validated those benefits in the context of
global sourcing with distributed teams?]

_Marvin

--- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...> wrote:
>
> You and your people need to decide, of course, and if you decide to go ahead, then TDD/BDD and so on are of
course the way to go.
> 
> Are you and your team skilled in those practices? If not, how do you plan to gain the needed skill in time?
> 
> Regards,
> 
> Ron Jeffries
> www.XProgramming.com
> You never know what is enough unless you know what is more than enough. -- William Blake

headers

Steve Ropa | 7 May 2012 17:46

RE: How to do this?

I know that I have been successful with BDD and its very close cousin ATDD.
I don't have any numbers to back that up, as I find most metrics to be
somewhat misleading at best, but I can definitely say that these practices
have led to a much more well tested product.  They also led to a much more
smooth path toward developing what my customer wants, rather than what I
think my customer wants.

Steve R.

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of MarvinToll.com
Sent: Monday, May 07, 2012 6:16 AM
To: extremeprogramming <at> yahoogroups.com
Subject: Re: [XP] How to do this?

Ron... I'm not trying to pick a fight on this... it is a legitimate
quesiton.

Has anyone made the factual case for BDD... beyond the benefits of TDD?

That is, if one is already practising TDD... what incremental costs/benefits
(in quantifiable terms) could one expect from addding BDD? [And perhaps, has
anyone validated those benefits in the context of global sourcing with
distributed teams?]

_Marvin

--- In extremeprogramming <at> yahoogroups.com
<mailto:extremeprogramming%40yahoogroups.com> , RonJeffries
<ronjeffries <at> ...> wrote:

(Continue reading)

headers

Curtis Cooley | 7 May 2012 17:52

Re: How to do this?

On Mon, May 7, 2012 at 8:46 AM, Steve Ropa <theropas <at> q.com> wrote:

> **
>
>
> I know that I have been successful with BDD and its very close cousin ATDD.
> I don't have any numbers to back that up, as I find most metrics to be
> somewhat misleading at best, but I can definitely say that these practices
> have led to a much more well tested product. They also led to a much more
> smooth path toward developing what my customer wants, rather than what I
> think my customer wants.
>
> Seems to be BDD is the way to go, since Theresa is trying to rewrite, and
thus reproduce, the behavior of an existing application.
--

-- 
--------------------------------------
Curtis Cooley
curtis <at> industriallogic.com

[Non-text portions of this message have been removed]

headers

Charlie Poole | 7 May 2012 18:23

Re: How to do this?

Please change the thread when you change the subject, especially when the
thread is about helping somebody with a problem.

Please.

Charlie

On Mon, May 7, 2012 at 5:15 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> Ron... I'm not trying to pick a fight on this... it is a legitimate
> quesiton.
>
> Has anyone made the factual case for BDD... beyond the benefits of TDD?
>
> That is, if one is already practising TDD... what incremental
> costs/benefits (in quantifiable terms) could one expect from addding BDD?
> [And perhaps, has anyone validated those benefits in the context of global
> sourcing with distributed teams?]
>
> _Marvin
>
> --- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...>
> wrote:
> >
> > You and your people need to decide, of course, and if you decide to go
> ahead, then TDD/BDD and so on are of course the way to go.
> >

(Continue reading)

headers

MarvinToll.com | 7 May 2012 20:47

Facts for incremental value of BDD? (Beyond TDD)

Charlie,

The linkage to the prior subject is whether a potential 'just enough' investment could be focused on TDD...
or is the added expense of BDD  worth the additional investment?

Ron's question:
> Are you and your team skilled in those practices? If not, how do you
> plan to gain the needed skill in time?

However, per your request... I'll start a new thread.

_Marvin

> On Mon, May 7, 2012 at 5:15 AM, MarvinToll.com <MarvinToll <at> ...>wrote:
> 
> > **
> >
> > Ron... I'm not trying to pick a fight on this... it is a legitimate
> > quesiton.
> >
> > Has anyone made the factual case for BDD... beyond the benefits of TDD?
> >
> > That is, if one is already practising TDD... what incremental
> > costs/benefits (in quantifiable terms) could one expect from addding BDD?
> > [And perhaps, has anyone validated those benefits in the context of global
> > sourcing with distributed teams?]
> >
> > _Marvin
> >
> > --- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> >

(Continue reading)

headers

Adam Sroka | 7 May 2012 21:02

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

There's no real practical difference between BDD and TDD when they are
practiced as intended. The difference is mainly one of terminology and
slightly one of philosophy although not really (Some of the BDD folks
interpret "top-down" narrowly and strictly and others don't. The same
permutations exist under the TDD umbrella, but strict top-down is less
common in my experience.)

There has been a lot of effort in the TDD community to differentiate
various styles. For the most part I feel it leads to interesting
discussions, but the distinctions aren't all that useful in practice.
Either you are driving from the tests (or whatever you choose to call them)
in small increments and mercilessly refactoring or not.

On Mon, May 7, 2012 at 11:47 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> Charlie,
>
> The linkage to the prior subject is whether a potential 'just enough'
> investment could be focused on TDD... or is the added expense of BDD worth
> the additional investment?
>
> Ron's question:
> > Are you and your team skilled in those practices? If not, how do you
> > plan to gain the needed skill in time?
>
> However, per your request... I'll start a new thread.
>

(Continue reading)

headers

RonJeffries | 7 May 2012 23:43

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

Hi Adam, and Marvin,

Marvin, I agree pretty much with what Adam is saying here, there is no practical difference.

"Said another way", your asking me for data about which is better tells me that, as yet, you do not understand
either one sufficiently to make good use use of the answer. It's like asking whether the best way to learn to
walk is to start with the left foot or the right.

Someone trying to decide choose between things that are this similar needs to understand how to do the
things in question, in their context, before deciding among them.

And in practice, someone who understands the fundamental ideas and practice behind TDD, ATDD, and BDD will
no longer even recognize this as a question. They will merely write the right test, at the right time, in the
right way.

Someone who doesn't understand deeply what these things are should just start learning them. It doesn't
matter where they start. They should start where their interest lies, or join the "school" of the
practitioner nearest to them.

When they can occasionally snatch the stone from my hand, or Adam's hand, or Charlie's hand, they will be
ready to ask sensible questions about the nuances. However, they won't need to ask such questions,
because the nuances they'll be dealing with will be much finer grain than anything we could say right now.

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". --
Mary Doria Russell

[Non-text portions of this message have been removed]

(Continue reading)

headers

JeffGrigg | 8 May 2012 03:27

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

Much of the motivation for creating BDD was to make TDD easier to learn.  The objective of BDD was to help
beginners reach a higher level of skill more quickly by addressing areas of common confusion in TDD by
changing the terminology and syntax so that they'd be more intuitive.

So for someone who does not already know either, I would most highly recommend learning BDD over
traditional TDD.  Because it's easier to learn.  You'll get up to speed more quickly.

Over time, I think that both end up in about the same place.  I like to describe BDD as "TDD done well."  The
better TDD developers would probably end up with BDD-like practices eventually.  Starting with BDD can
shorten the learning curve by teaching better practices up-front.

(Of course a good TDD instructor is likely to teach you good practices, even if they don't call it BDD.)

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> The linkage to the prior subject is whether a potential 'just
> enough' investment could be focused on TDD... or is the added
> expense of BDD  worth the additional investment?

> --- Ron's question:
>> Are you and your team skilled in those practices? If not,
>> how do you plan to gain the needed skill in time?

headers

Charlie Poole | 8 May 2012 05:00

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

As I've written elsewhere, I had a very unfriendly and confrontational
("You don't know what you're doing") introduction to BDD, so perhaps I'm
predjudiced. OTOH, I think it's fair to think badly of an approach that
leads people to put down what others do. It's not something we need in the
agile world. In fairness, I admit that some outsiders see XP in exactly
that way, based on what they have heard from so-called XP folks. I make no
claim to be either right or consistent in this.

All that said, I find myself pretty much in agreement with those who talk
about BDD as TDD done well and wouldn't mind referring somebody to an
instructor with that view. There are other self-styled BDD practitioners,
however, who don't do much true unit testing and I wouldn't want to turn a
beginner over to be instructed by such a person.

As for the terminology, I must admit that I never liked it - and still
don't. Since use of the terminology is how BDD, TDD,  XP, Scrum, etc. folks
recognize one another, I'm sure I'll never be mistaken for a BDD guy - even
if I do some of the same things as others who use the terms.

Charlie

On Mon, May 7, 2012 at 6:27 PM, JeffGrigg <jeffreytoddgrigg <at> gmail.com>wrote:

> **
>
>
> Much of the motivation for creating BDD was to make TDD easier to learn.
> The objective of BDD was to help beginners reach a higher level of skill
> more quickly by addressing areas of common confusion in TDD by changing the
> terminology and syntax so that they'd be more intuitive.

(Continue reading)

headers

M. Manca | 8 May 2012 08:43

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

I think that both BDD and TDD are good practices. In my opinion BDD is
simpler to understand for the beginner and it is easier to use to write
acceptance tests starting from user stories. It is mainly a linguistic
difference so I should say that BDD helps to "translate" user stories
into executable tests better then TDD.

In my daily practice I find useful to use BDD to develop the application
trunk guided by acceptance tests (written first) realized following BDD.
But this in embedded applications may not be enough simply because some
features are hidden to user stories at customer level needing to
explicit them during the development for the benefit of the team
members. In these cases and also to divide the work among the team
members may be better to use a limited bottom up approach with the help
of TDD that seems to me better tailored to these situations because for
the acceptance tests we don't require these "internal" tests but we
require them as unit tests.

Il 08/05/2012 05:00, Charlie Poole ha scritto:
> As I've written elsewhere, I had a very unfriendly and confrontational
> ("You don't know what you're doing") introduction to BDD, so perhaps I'm
> predjudiced. OTOH, I think it's fair to think badly of an approach that
> leads people to put down what others do. It's not something we need in the
> agile world. In fairness, I admit that some outsiders see XP in exactly
> that way, based on what they have heard from so-called XP folks. I make no
> claim to be either right or consistent in this.
>
> All that said, I find myself pretty much in agreement with those who talk
> about BDD as TDD done well and wouldn't mind referring somebody to an
> instructor with that view. There are other self-styled BDD practitioners,
> however, who don't do much true unit testing and I wouldn't want to turn a

(Continue reading)

headers

PAUL | 8 May 2012 11:14

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


Hi All,

I avoided the distinction between unit/acceptance and TDD/BDD in my response to Theresa precisely
because of the confusion this can cause. Like someone said, the right tests at the right time is what is
needed :)

if you ask Dan North, BDD was meant to help. Unfortunately for those in search of a simple recipe in my
experience it hasn't helped at all.

The problem I've seen is that many people don't understand testing and how it relates to design, so try and
use one kind of test/spec to cover everything. You can do both white box and black box testing/
specification using BDD. A test specification, can be a design spec (unit) or a requirements spec
(acceptance). It's up to you.

There are lots of people who don't have a deep understand of TDD or BDD, not surprising because it's a
difficult skill to acquire.

The worrying thing for me is that there is a growing body of developers who don't understand TDD/BDD, yet see
themselves as experts. I think the problem is how we teach this stuff. There seems to be a move to try and
short circuit all the software engineering theory, and focus soley on practice. The result is
practitioners who lack a solid foundation. Perhaps all that software engineering stuff is a useful
background to have?

I've had similar experiences to Charlie. BDDers telling me I don't know what I'm doing. I couldn't explain
otherwise, because they knew it already :)

Paul.

--- In extremeprogramming <at> yahoogroups.com, "M. Manca" <m.manca <at> ...> wrote:

(Continue reading)

headers

RonJeffries | 8 May 2012 11:27

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

All,

On May 8, 2012, at 5:14 AM, PAUL wrote:

> I avoided the distinction between unit/acceptance and TDD/BDD in my response to Theresa precisely
because of the confusion this can cause. Like someone said, the right tests at the right time is what is
needed :)

One thing that is worth "knowing" is that when Chris Matts and Liz Keogh talk about BDD, they seem to mean
something very different from what Dan North called BDD. Their deal is more like ATDD to me but I cannot do it
justice. I do believe, based on long chats with each of them, that they have some good ideas.

My point remains, however, that it is way too soon to look for incremental differences between these things
when one doesn't know any of them well. First get to Cleveland, then look for the place that puts egg on the
pizza, then decide which sauce you like on the fries.

Ron Jeffries
www.XProgramming.com
If it is more than you need, it is waste. -- Andy Seidl

[Non-text portions of this message have been removed]

headers

M. Manca | 8 May 2012 13:00

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

Ron,
do you think that ATDD and BDD are different answers to
simplify/discipline TDD learning?
What between BDD and ATDD fits better to translate a requirement to an
executable requirement in your opinion?
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.
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.

Il 08/05/2012 11:27, RonJeffries ha scritto:
>  
>
> All,
>
> On May 8, 2012, at 5:14 AM, PAUL wrote:
>
> > I avoided the distinction between unit/acceptance and TDD/BDD in my
> response to Theresa precisely because of the confusion this can cause.
> Like someone said, the right tests at the right time is what is needed :)
>
> One thing that is worth "knowing" is that when Chris Matts and Liz
> Keogh talk about BDD, they seem to mean something very different from
> what Dan North called BDD. Their deal is more like ATDD to me but I
> cannot do it justice. I do believe, based on long chats with each of
> them, that they have some good ideas.
>
> My point remains, however, that it is way too soon to look for

(Continue reading)

headers

RonJeffries | 8 May 2012 13:50

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

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.

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.

(Continue reading)

headers

Steven Gordon | 8 May 2012 14:51

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

On Tue, May 8, 2012 at 4:50 AM, RonJeffries <ronjeffries <at> acm.org> wrote:
>
>
> 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.
>
>
It is ironic, but not too surprising, that this exercise would be much
easier for somebody whose only knowledge of the concepts is from reading
about them.

> 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]

headers

M. Manca | 8 May 2012 16:43

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

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

(Continue reading)

headers

Charlie Poole | 8 May 2012 17:24

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

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 <at> micronengineering.it>wrote:

> **
>
>
> Il 08/05/2012 13:50, RonJeffries ha scritto:

(Continue reading)

headers

M. Manca | 8 May 2012 18:00

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

Il 08/05/2012 17:24, Charlie Poole ha scritto:
I think that we all agree about importance and utility of these
practices, I like to understand different opinions to improve my
experience about them and refine my implementations.

Previously I said that I prefer to follow BDD for acceptance tests (for
me they are the same of customer tests) and TDD for unit tests/developer
test. Is this contest near to your idea? Or would you prefer ATDD
instead BDD? I noted that when I develop better the application I need
only 2 test types: acceptance/customer tests and unit tests and I don't
need what is already called "integration tests". Do you think that this
may be a general solution or it may be specific of a subset of applications?

> 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 also like this vision and I feel more simple to use BDD for customer
tests and leaving some freedom to the team members to use TDD or BDD for
their unit tests. Mainly our procedure is to write acceptance tests
first, then start to implement high level features initially using mocks
to isolate low level features (that also don't exist yet, we normally
work on embedded system projects). When we are implementing low level
features normally their requirements arise by itself so rarely we need
to formalize them as user stories; so the engineer may choose freely
between BDD and TDD to unit test the features. When the features will be
ready they will be put in the main development trunk substituting the
mocks so that the acceptance tests will be run with the real low level
features and obviously they should pass.

(Continue reading)

headers

Charlie Poole | 8 May 2012 18:46

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

Hi,

On Tue, May 8, 2012 at 9:00 AM, M. Manca <m.manca <at> micronengineering.it> wrote:
> Previously I said that I prefer to follow BDD for acceptance tests (for
> me they are the same of customer tests) and TDD for unit tests/developer
> test. Is this contest near to your idea? Or would you prefer ATDD
> instead BDD?

To clarify what I already wrote, I never use this terminology in my work.
So, in your view, what are the key differences between BDD and ATDD?

> I noted that when I develop better the application I need
> only 2 test types: acceptance/customer tests and unit tests and I don't
> need what is already called "integration tests". Do you think that this
> may be a general solution or it may be specific of a subset of applications?

Well, "integration tests" means different things to different people. My own
experience is that tests integrating separate high-level components are
needed in complex applications. They are not unit tests, because they
include many many classes and methods. But they sometimes don't rise
to the level of a user story.

IME, this need is very rare. It almost never exists in typical
business applications.
>
>
>
> > 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

(Continue reading)

headers

M. Manca | 8 May 2012 20:11

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

Il 08/05/2012 18:46, Charlie Poole ha scritto:
> Hi,
>
> On Tue, May 8, 2012 at 9:00 AM, M. Manca <m.manca <at> micronengineering.it> wrote:
>> Previously I said that I prefer to follow BDD for acceptance tests (for
>> me they are the same of customer tests) and TDD for unit tests/developer
>> test. Is this contest near to your idea? Or would you prefer ATDD
>> instead BDD?
> To clarify what I already wrote, I never use this terminology in my work.
> So, in your view, what are the key differences between BDD and ATDD?
Well, for me is more obvious that ATDD is related to acceptance/customer
tests then BDD from a lexical point of view and for its definition or
the definitions I found looking around on the web.

I have to admit that I feel more natural to use gherkin syntax to
express acceptance/customer tests so I should say that I am using BDD to
drive the development writing acceptance/customer tests.

Also I read a lot of articles and documentation about ATDD and BDD from
their original authors and from coaches and speakers. I think their
different point of view are causing a lot of confusion and different
understandings and opinions especially about BDD, if BDD means TDD done
well or if BDD meand ATDD done well and so on. I think also that there
is too much nomenclature for very similar practices and that new
nomenclature are continuously introduced for very little practice variants.
>
>> I noted that when I develop better the application I need
>> only 2 test types: acceptance/customer tests and unit tests and I don't
>> need what is already called "integration tests". Do you think that this
>> may be a general solution or it may be specific of a subset of applications?

(Continue reading)

headers

Josue Barbosa dos Santos | 8 May 2012 20:24

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

My current understanding of the BDD/TDD definitions:

Yesterday:
BDD = TDD + changing the naming to not focus on test, but in
specification  (given,
when , then, should etc.)

Today:
BDD = ATDD + TDD  + changing the naming to not focus on test, but in
specification  (given, when , then, should etc.)

--

-- 
Abraços,
Josué
http://twitter.com/josuesantos

On Tue, May 8, 2012 at 3:11 PM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>
>
> Il 08/05/2012 18:46, Charlie Poole ha scritto:
> > Hi,
> >
>
> > On Tue, May 8, 2012 at 9:00 AM, M. Manca <m.manca <at> micronengineering.it>
> wrote:
> >> Previously I said that I prefer to follow BDD for acceptance tests (for
> >> me they are the same of customer tests) and TDD for unit tests/developer
> >> test. Is this contest near to your idea? Or would you prefer ATDD

(Continue reading)

headers

Charlie Poole | 8 May 2012 20:34

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

Hi Josué,

I think that's right for some people - those who made the transition from
what you call Yesterday to what you call Today. But others seem to continue
in the original definition.

My own definition is that the original BDD is a style of TDD, and wasn't
worthy of a separate name in the first place. The 'Today' style is a bit
different in that it seems to blur an important distinction, which has
always been present in XP.

Charlie

On Tue, May 8, 2012 at 11:24 AM, Josue Barbosa dos Santos
<josuesantos <at> gmail.com> wrote:
> My current understanding of the BDD/TDD definitions:
>
> Yesterday:
> BDD = TDD + changing the naming to not focus on test, but in
> specification  (given,
> when , then, should etc.)
>
> Today:
> BDD = ATDD + TDD  + changing the naming to not focus on test, but in
> specification  (given, when , then, should etc.)
>
> --
> Abraços,
> Josué
> http://twitter.com/josuesantos

(Continue reading)

headers

PAUL | 8 May 2012 22:12

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


Hi Charlie,

--- In extremeprogramming <at> yahoogroups.com, Charlie Poole <charliepoole <at> ...> wrote:
>. The 'Today' style is a bit
> different in that it seems to blur an important distinction, which has
> always been present in XP.

Not just a distinction held as important by XP, but by the whole body of knowledge commonly referred to as
Software Engineering too.

(ps. I'm not a fan of the term "Software Engineering", but with its rapid demise we've seemed to have thrown
out the baby with the bath water)

Paul.
> 
> Charlie
> 
> On Tue, May 8, 2012 at 11:24 AM, Josue Barbosa dos Santos
> <josuesantos <at> ...> wrote:
> > My current understanding of the BDD/TDD definitions:
> >
> > Yesterday:
> > BDD = TDD + changing the naming to not focus on test, but in
> > specification  (given,
> > when , then, should etc.)
> >
> > Today:
> > BDD = ATDD + TDD  + changing the naming to not focus on test, but in
> > specification  (given, when , then, should etc.)

(Continue reading)

headers

Charlie Poole | 8 May 2012 20:28

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

I agree that the Gherkin DSL is one excellent way to express customer
tests, but
I don't think we should confuse tools with methodologies.

Part of what bothers me about the BDD movement is that it focuses a great
deal
on two non-essentials: tools and terminology. Once you have mastered TDD,
you can do it with whatever tools are available and you can call it whatever
you want without confusion.

That's not to say the tools aren't important. Better tools help us to work
more
effectively and naturally. But in spite of my being a tool-maker, I don't
think
any tool is central to the process.

Charlie

>  Il 08/05/2012 18:46, Charlie Poole ha scritto:
> > Hi,
> >
>
> > On Tue, May 8, 2012 at 9:00 AM, M. Manca <m.manca <at> micronengineering.it>
> wrote:
> >> Previously I said that I prefer to follow BDD for acceptance tests (for
> >> me they are the same of customer tests) and TDD for unit tests/developer
> >> test. Is this contest near to your idea? Or would you prefer ATDD
> >> instead BDD?
> > To clarify what I already wrote, I never use this terminology in my work.
> > So, in your view, what are the key differences between BDD and ATDD?

(Continue reading)

headers

MarvinToll.com | 9 May 2012 14:31

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

I'm not ready to agree to the importance and utility of BDD.

Thus the reason I asked for Facts that would help me prioritize whether to invest my free time in BDD or other
recent "inflated expectations" (Gartner Hype Cycle)... such as additional functional programming languages.

--- In extremeprogramming <at> yahoogroups.com, "M. Manca" <m.manca <at> ...> wrote:
>
> Il 08/05/2012 17:24, Charlie Poole ha scritto:
> I think that we all agree about importance and utility of these
> practices, I like to understand different opinions to improve my
> experience about them and refine my implementations.

headers

RonJeffries | 9 May 2012 14:39

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

Hello, Marvin,

On May 9, 2012, at 8:31 AM, MarvinToll.com wrote:

> I'm not ready to agree to the importance and utility of BDD.
> 
> Thus the reason I asked for Facts that would help me prioritize whether to invest my free time in BDD or other
recent "inflated expectations" (Gartner Hype Cycle)... such as additional functional programming languages.

As you know, "Facts", even capitalized, do not often convince people to try things.

Let us know when you are interested in actually trying to learn some of the XP and related practices. We'll be
glad to try to help you.

We are not here to try to convince you what to do. We are here to help you do it.

Ron Jeffries
www.XProgramming.com
If not now, when? -- Rabbi Hillel

[Non-text portions of this message have been removed]

headers

MarvinToll.com | 9 May 2012 14:50

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

Ron,

Are you saying BDD is now an XP practise?

If so, what was the rationale for its inclusion?

_Marvin

--- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...> wrote:
>
> Hello, Marvin,
> 
> On May 9, 2012, at 8:31 AM, MarvinToll.com wrote:
> 
> > I'm not ready to agree to the importance and utility of BDD.
> > 
> > Thus the reason I asked for Facts that would help me prioritize whether to invest my free time in BDD or
other recent "inflated expectations" (Gartner Hype Cycle)... such as additional functional
programming languages.
> 
> As you know, "Facts", even capitalized, do not often convince people to try things.
> 
> Let us know when you are interested in actually trying to learn some of the XP and related practices. We'll
be glad to try to help you.
> 
> We are not here to try to convince you what to do. We are here to help you do it.
> 
> 
> Ron Jeffries
> www.XProgramming.com

(Continue reading)

headers

RonJeffries | 9 May 2012 15:16

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

Marvin,

On May 9, 2012, at 8:50 AM, MarvinToll.com wrote:

> Are you saying BDD is now an XP practise?
> 
> If so, what was the rationale for its inclusion?

If you'll read carefully, i.e. all the words, you'll see that I said our purpose here is to help people learn
to do XP and related practices.

If and when you want to really learn how to do some of these things, this would be one good place to inquire.

Ron Jeffries
www.XProgramming.com
Sometimes I give myself admirable advice, but I am incapable of taking it.
-- Mary Wortley Montagu

[Non-text portions of this message have been removed]

headers

M. Manca | 9 May 2012 17:04

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

Ron,
yesterday you and Charlie were interested to understand why there are so
many engineers that correlate BDD to acceptance tests/customer tests. I
can't say that it is an exhaustive report but I find some documents that
may help you that this confusion came from a lot of documents as this:
http://www.ibm.com/developerworks/java/tutorials/j-easyb/j-easyb-pdf.pdf
You will see that there is a chapter named: "BDD: Customer-focused TDD".

[The author is Andrew Glover:
Andrew Glover
Andrew Glover is a developer, author, speaker, and entrepreneur with a
passion for behavior-driven development, Continuous Integration, and
Agile software development. You can keep up with him at his blog:
http://www.thediscoblog.com/]

At http://msdn.microsoft.com/en-us/magazine/gg490346.aspx you may read
an article written by Brandon Satrom (I don't know him)
He wrote this piece of text that summarize what he thinks:

"In 2006, Dan North documented many of these challenges in an article in
/Better Software/ magazine (blog.dannorth.net/introducing-bdd
<http://blog.dannorth.net/introducing-bdd>). In his article, North
described a series of practices that he had adopted over the prior three
years while in the trenches with testing. While still TDD by definition,
these practices led North to adopt a more analysis-centric view of
testing and to coin the term Behavior-Driven Development to encapsulate
this shift.One popular application of BDD attempts to extend TDD by
tightening the focus and process of creating tests through Acceptance
Tests, or executable specifications. Each specification serves as an
entry point into the development cycle and describes, from the user's

(Continue reading)

headers

Charlie Poole | 9 May 2012 17:23

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

Hi,

I think you may have misunderstood me - and perhaps Ron as well.

I'm pretty familiar with the history of BDD and have read much of what you
list
there. I have tried several so-called BDD tools and like some of them for
some
purposes.

I'm very familiar with the fact that there are lots of definitions and
that's
why I asked what _you_ meant by BDD. From your answer, I gather that
it's customer-oriented testing using a tool that features given-when-then
syntax. Knowing _your_ definition helps me to exchange ideas with you.

I don't think that there's a right answer to the "What is BDD?" question,
but there is a right answer to "What do you mean when you say BDD?"

What we do is what is important, not what we call it. When I write
acceptance tests using a cucumber-like tool, I don't call it BDD. When
I write acceptance tests using FIT, I don't call it anti-BDD either. I
just tend to call it "Writing acceptance tests."

Charlie

On Wed, May 9, 2012 at 8:04 AM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>

(Continue reading)

headers

M. Manca | 9 May 2012 17:46

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

Il 09/05/2012 17:23, Charlie Poole ha scritto:
> Hi,
>
> I think you may have misunderstood me - and perhaps Ron as well.
May be I misunderstood you, more or less my idea wasn't to be who of us
is right or find an universal definition about what is BDD and what is
not. I admitted from the beginning that I have a difficulty to tell what
I think because there are too much terms to say more or less the same
thing in a half dozen ways.
>
> I'm pretty familiar with the history of BDD and have read much of what you
> list
> there. I have tried several so-called BDD tools and like some of them for
> some
> purposes.
Of course I didn't copy and paste for this reason, I was only surprised
to read so many different interpretations. May be that some times a more
formal definition of BDD may define better its boundaries.
I think that XP is better defined, it is more clear what is and what
practices provides.
>
> I'm very familiar with the fact that there are lots of definitions and
> that's
> why I asked what _you_ meant by BDD. 
Ok, now I understand better.
> From your answer, I gather that
> it's customer-oriented testing using a tool that features given-when-then
> syntax. Knowing _your_ definition helps me to exchange ideas with you.
>
> I don't think that there's a right answer to the "What is BDD?" question,

(Continue reading)

headers

Steven Gordon | 9 May 2012 18:03

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

On Wed, May 9, 2012 at 8:46 AM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>
>  May be that some times a more
> formal definition of BDD may define better its boundaries.
>

Nobody here is in a position to provide an official formal definition of
BDD.  Its adherents may well be too fragmented for that to ever happen.

That said, I will provide an unofficial definition that may help you: I
think of BDD as a particular way to think about tests that motivates using
some specific kinds of terminologies and formats.

BDD has been usefully applied to both TDD and ATDD, but that does not make
BDD itself a variant of either.  It is just a slightly different way to do
either.  There is no reason that BDD might not prove useful in other
testing domains besides programmer tests or customer tests.

Sometimes the BDD way of thinking is useful, sometimes maybe not.  My
experience has been that it has helped me more in ATDD than in TDD, but
that might just be due to the particular contexts I have coached and worked
in since BDD was introduced (or that my TDD experience was more established
before BDD than my ATDD experience).

SteveG

[Non-text portions of this message have been removed]

(Continue reading)

headers

Charlie Poole | 9 May 2012 18:30

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

Hi Steven,

This pretty much matches my view of BDD.

Back when BDD was first talked about, I did a tongue-in-cheek presentation
a few times called "Why I'll Still Do TDD (even though BDD has a point)"
Mainly, I  thought - still think - that there are some good ideas in BDD
but that calling it something different from TDD was just confusing.

The two biggest contributions of BDD to (at least my) TDD have been
* The notion of organizing tests by a context
* The importance of syntax in testing tools

Charlie

On Wed, May 9, 2012 at 9:03 AM, Steven Gordon <sgordonphd <at> gmail.com> wrote:

> **
>
>
> On Wed, May 9, 2012 at 8:46 AM, M. Manca <m.manca <at> micronengineering.it
> >wrote:
>
> > **
> >
>
> > May be that some times a more
> > formal definition of BDD may define better its boundaries.
> >
>

(Continue reading)

headers

Adam Sroka | 9 May 2012 19:38

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

I got involved with the TDD community in Java in about 2001. I was
introduced to BDD via Rspec and Ruby thanks to Dave Astels around
2004. I've done a lot of xUnit in other languages and a bit of xSpec
in other languages as well. One of my current favorite environments to
work in is Jasmine/JavaScript.

I haven't done /as much/ ATDD, but I have taught it using FIT,
FitNesse, Cucumber, xUnit, and a few other tools. The BDD folks
incorporate this under a single banner.

I have a philosophical problem with ATDD as I usually see it practiced
in that I think the line between programmer and customer tests is
blurrier than some insist it is. For example, is the very first
Cucumber scenario you write a customer or programmer test? If you are
following the principles then you must do the simplest thing that can
work and add more tests to compel additional behavior. That means you
*must* fake it at this point. However, if you fake it and the test
passes have you really done what the customer expected? If not, can we
really call this a customer test?

In other words, I think there is a cognitive dissonance between the
principles of TDD and the intent of ATDD. I don't, in my own work, use
anything other than xUnit/xSpec to write customer tests. Using a
different framework doesn't save you from writing the wrong kind of
tests, and customers aren't generally savvy enough to tell the
difference between a good customer test and a programmer test written
in Cucumber.

On Wed, May 9, 2012 at 9:30 AM, Charlie Poole <charliepoole <at> gmail.com> wrote:
> Hi Steven,

(Continue reading)

headers

Steven Gordon | 9 May 2012 20:24

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

On Wed, May 9, 2012 at 10:38 AM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
>
> In other words, I think there is a cognitive dissonance between the
> principles of TDD and the intent of ATDD. I don't, in my own work, use
> anything other than xUnit/xSpec to write customer tests. Using a
> different framework doesn't save you from writing the wrong kind of
> tests, and customers aren't generally savvy enough to tell the
> difference between a good customer test and a programmer test written
> in Cucumber.
>

In many larger organizations adopting Agile, there is an army of Business
Analysts who must be leveraged.

BAs are people who understand both the customer and the software
development process well enough to easily trained to become "savvy" enough
to create meaningful and useful first "customer tests" that suitably
represent the happy paths of well-defined user stories.  And unlike the
actual customer, they are available full-time, so they can actively
collaborate with the developers and testers on creating subsequent
"customer tests" that have a good chance of actually representing what the
real customer wants.  Having these tests written is as close to human
language using the business domain terminology and be easily available
outside the programming infrastructure has big benefits in this kind of
enterprise.

SteveG

>
>

(Continue reading)

headers

Adam Sroka | 9 May 2012 20:39

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

On Wed, May 9, 2012 at 11:24 AM, Steven Gordon <sgordonphd <at> gmail.com> wrote:
> On Wed, May 9, 2012 at 10:38 AM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
>>
>> In other words, I think there is a cognitive dissonance between the
>> principles of TDD and the intent of ATDD. I don't, in my own work, use
>> anything other than xUnit/xSpec to write customer tests. Using a
>> different framework doesn't save you from writing the wrong kind of
>> tests, and customers aren't generally savvy enough to tell the
>> difference between a good customer test and a programmer test written
>> in Cucumber.
>>
>
> In many larger organizations adopting Agile, there is an army of Business
> Analysts who must be leveraged.
>
> BAs are people who understand both the customer and the software
> development process well enough to easily trained to become "savvy" enough
> to create meaningful and useful first "customer tests" that suitably
> represent the happy paths of well-defined user stories.  And unlike the
> actual customer, they are available full-time, so they can actively
> collaborate with the developers and testers on creating subsequent
> "customer tests" that have a good chance of actually representing what the
> real customer wants.  Having these tests written is as close to human
> language using the business domain terminology and be easily available
> outside the programming infrastructure has big benefits in this kind of
> enterprise.
>

It probably doesn't suck nearly as bad as whatever they were doing
before. It is not really related to TDD, though. The problem is that a

(Continue reading)

headers

Theresa Forster | 9 May 2012 20:44

RE: Re: Facts for incremental value of BDD? (Beyond TDD)

Just wondering why no one has yet put out what they think BDD means

Behavior-driven development (or BDD) is an agile software development
<http://en.wikipedia.org/wiki/Agile_software_development>  technique devised
by Dan North[1]
<http://en.wikipedia.org/wiki/Behavior_Driven_Development#cite_note-origin-0
>  as a response to the issues he encountered whilst teaching Test-Driven
Development <http://en.wikipedia.org/wiki/Test-Driven_Development> :[1]
<http://en.wikipedia.org/wiki/Behavior_Driven_Development#cite_note-origin-0
> 

*	Where to start in the process
*	What to test and what not to test
*	How much to test in one go
*	What to call the tests
*	How to understand why a test fails

At the heart of BDD is a rethinking of the approach to unit testing and
acceptance testing: unit test names are whole sentences starting with the
word "should" and they are written in order of business value. Acceptance
tests are written using the standard agile framework of a User story
<http://en.wikipedia.org/wiki/User_story> : "As a [role] I want [feature] so
that [benefit]". Acceptance criteria are written in terms of scenarios and
implemented as classes: Given [initial context], when [event occurs], then
[ensure some outcomes].[1]
<http://en.wikipedia.org/wiki/Behavior_Driven_Development#cite_note-origin-0
> 

Its about the naming  of tests, ie

(Continue reading)

headers

Jeff Langr | 9 May 2012 21:28

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

On Wed, May 9, 2012 at 12:44 PM, Theresa Forster <theresajayne <at> minuet-uk.com
> wrote:

Just wondering why no one has yet put out what they think BDD means
>

Thanks Theresa,

I think Ron suggested putting something side by side to show the
differences. I'd love to see that. For example, I might find something
helpful something that said "If you are doing TDD but you are not doing X,
then you are not doing BDD." (hmm... that might make for a good Agile in a
Flash card blog entry)

The Wikipedia definition below says: 'unit test names are whole sentences
starting with the word "should." ' So, for example, if your test name does
not start with "should," then are you not BD?   I bet some people who
think they are doing BDD would object to that thought.

I've tried to find a good concrete definition of BDD as it relates to (or
contrasts with) TDD a few times, always getting mildly frustrated. I end up
with lots of little questions. For example, what exactly does "unit test
[names?] ... are written in order of business value" really mean? Must unit
test names (per wikipedia) they really be whole sentences? And so on. It
doesn't keep me up nights, but it would be nice to know what to say about
BDD when asked.

Regards,
Jeff

(Continue reading)

headers

RonJeffries | 9 May 2012 22:03

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

Hi Jeff,

On May 9, 2012, at 3:28 PM, Jeff Langr wrote:

> I've tried to find a good concrete definition of BDD as it relates to (or
> contrasts with) TDD a few times, always getting mildly frustrated. I end up
> with lots of little questions. For example, what exactly does "unit test
> [names?] ... are written in order of business value" really mean? Must unit
> test names (per wikipedia) they really be whole sentences? And so on. It
> doesn't keep me up nights, but it would be nice to know what to say about
> BDD when asked.

Yes. Back when I was first trying to understand what the [then] BDD people were on about, it seemed like this:

They said TDD was about writing unit tests that tested the methods you planned to write. They thought that
one should test the object behavior one was trying to create, so they focused on BEHAVIOR driven
development. 

This was confusing to me and all of us'ns around here because we always knew that TDD was about saying what you
wanted the object to do, and then doing it. 

There was also the notion of the "Detroit School" of TDD and the "London School". I have no idea who came up
with these names. The London school took a very isolationist approach, focused on testing a single
object, plugging in mocks, stubs, and various kind of test doubles so as to test just one test at a time. We in
the Detroit School just tested the system's behavior. We might use a mock object to disconnect from a
database or something. We didn't use them as a matter of course. 

It would often turn out that as we built something up, we would stub out behavior in whatever class we were
talking to, or in some related class. The famous "return 0;" as the first implementation of bowling
scoring is an example of this. One moment we'd have a constant. In a little while we might have an object with

(Continue reading)

headers

Adam Sroka | 9 May 2012 22:48

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

Hi Ron:

Nice summary. I believe the following things, which I think are about 99%
in agreement with what you wrote:

1) There is a part of BDD that is just TDD with different names. There is
no substantive difference there other than that someone new might find one
description or the other more intuitive.

2) There is a part of BDD that is a lot like ATDD. ATDD is useful technique
that also comes from XP, but it is like TDD by analogy only. It is not the
same process.

(Some of the literature doesn't make the customer/programmer testing
distinction well enough, IMO. And, in practice I have seen a lot of what I
would call programmer integration testing being passed off as ATDD or
"feature"-level BDD.)

3) There is a whole other part of the discussion about how/when to use
mocking/stubbing. I'm not sure it does anything but muddy the waters at
this point. Except, it does often get conflated with the other two things.

I believe the name "London School" is a result of JMock and the GOOS book.
Steve and Nat do express some views that are similar to the BDD crowd, but
they don't call it BDD. J.B. Rainsberger has also written and spoken quite
eloquently on the advantages of a mock-based approach. He's not from
London, and he's not a BDDer, AFAIK.

There are probably several more people I could lump into that category,
including myself (I use a lot of mocks at times, not always just at system

(Continue reading)

headers

Adam Sroka | 9 May 2012 22:49

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

LOL. Maybe not 99% after the second round of editing. I'll leave it as an
exercise to determine the actual percentage of my agreement :-D

On Wed, May 9, 2012 at 1:48 PM, Adam Sroka <adam.sroka <at> gmail.com> wrote:

> Hi Ron:
>
> Nice summary. I believe the following things, which I think are about 99%
> in agreement with what you wrote:
>
> 1) There is a part of BDD that is just TDD with different names. There is
> no substantive difference there other than that someone new might find one
> description or the other more intuitive.
>
> 2) There is a part of BDD that is a lot like ATDD. ATDD is useful
> technique that also comes from XP, but it is like TDD by analogy only. It
> is not the same process.
>
> (Some of the literature doesn't make the customer/programmer testing
> distinction well enough, IMO. And, in practice I have seen a lot of what I
> would call programmer integration testing being passed off as ATDD or
> "feature"-level BDD.)
>
> 3) There is a whole other part of the discussion about how/when to use
> mocking/stubbing. I'm not sure it does anything but muddy the waters at
> this point. Except, it does often get conflated with the other two things.
>
> I believe the name "London School" is a result of JMock and the GOOS book.
> Steve and Nat do express some views that are similar to the BDD crowd, but
> they don't call it BDD. J.B. Rainsberger has also written and spoken quite

(Continue reading)

headers

Adam Sroka | 9 May 2012 23:03

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

Another random thought:

For the past couple of years when I teach TDD classes I always point out
that some folks say, "Arrange, Act, Assert," and others say "Given, When,
Then," and they both mean exactly the same thing.

In hindsight I suppose the question is whether alliteration or formal logic
resonates more with you? 

[Non-text portions of this message have been removed]

headers

JeffGrigg | 10 May 2012 00:14

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

--- Adam Sroka <adam.sroka <at> ...> wrote:
> ... "Arrange, Act, Assert," ... "Given, When, Then,"
> and they both mean exactly the same thing.

And then there is the "dogmatic -to- pragmatic" dimension too:

I think that the "Arrange, Act, Assert" and "Given, When, Then" forms are good patterns to follow.  (And "one
assert per test" is a good idea.)  ...until I write a test that looks nothing like that.  Yes, I know that my
nasty test won't give me desirable property "X" that the simply patterned tests have.  But often there's no
sane way to do that, so I go with what works over what complies with some artificial stricture.

headers

Jeff Langr | 10 May 2012 16:41

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

On Wed, May 9, 2012 at 4:14 PM, JeffGrigg <jeffreytoddgrigg <at> gmail.com>
 wrote:

> I think that the "Arrange, Act, Assert" and "Given, When, Then" forms are
> good patterns to follow.  (And "one assert per test" is a good idea.)
>  ...until I write a test that looks nothing like that.  Yes, I know that my
> nasty test won't give me desirable property "X" that the simply patterned
> tests have.  But often there's no sane way to do that, so I go with what
> works over what complies with some artificial stricture.
>

Yeah. BDD-style naming, write asserts first, one assert per test, AAA test
organization, 10-minute rule, and so on are all good ideas, and I do every
one (well, not true, I don't find writing asserts first all that helpful
for me) most of the time... until "there's no sane way to do that." Rules
are made to be broken.

It's all test-driven development to me.

Jeff

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com <http://agileinaflash.com--/> - Agile in a Flash:
the most comprehensive agile reference & source of wisdom available!

[Non-text portions of this message have been removed]

headers

extremeprogrammer | 11 May 2012 14:06

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

I concur.

Judean People's Front... People's Front of Judea.

--- In extremeprogramming <at> yahoogroups.com, Jeff Langr <jeff <at> ...> wrote:
> 
> It's all test-driven development to me.

headers

Amir Kolsky | 11 May 2012 17:34

RE: Re: Facts for incremental value of BDD? (Beyond TDD)

+1

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of extremeprogrammer
Sent: Friday, May 11, 2012 5:07 AM
To: extremeprogramming <at> yahoogroups.com
Subject: [XP] Re: Facts for incremental value of BDD? (Beyond TDD)

I concur.

Judean People's Front... People's Front of Judea.

--- In extremeprogramming <at> yahoogroups.com
<mailto:extremeprogramming%40yahoogroups.com> , Jeff Langr <jeff <at> ...> wrote:
> 
> It's all test-driven development to me.

[Non-text portions of this message have been removed]

headers

M. Manca | 9 May 2012 23:06

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

Hi Ron,
this is one of the longer posts I remember you wrote here .

You are not alone, as I said I am in the set of engineers that didn't
understand "Feature Injection". Yes, here in the old Europe there is a
group of engineers that thinks is better to execute unit tests in a
perfect isolation removing every dependency. There is a lot of debate
here about test isolation, mocks, testing doubles and so on. They spend
also a lot of time in conferences and meetings to discuss about test
isolation, test formalism and test content. Ok these are interesting
arguments but I don't think so much interesting to debate at every
conference with very little news every time.

Personally I prefer a little more pragmatic approach like the Detroit group.

Il 09/05/2012 22:03, RonJeffries ha scritto:
>  
>
> Hi Jeff,
>
> On May 9, 2012, at 3:28 PM, Jeff Langr wrote:
>
> > I've tried to find a good concrete definition of BDD as it relates
> to (or
> > contrasts with) TDD a few times, always getting mildly frustrated. I
> end up
> > with lots of little questions. For example, what exactly does "unit test
> > [names?] ... are written in order of business value" really mean?
> Must unit
> > test names (per wikipedia) they really be whole sentences? And so on. It

(Continue reading)

headers

Joshua Kerievsky | 9 May 2012 23:29

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

On Wed, May 9, 2012 at 1:03 PM, RonJeffries <ronjeffries <at> acm.org> wrote:

> XP has always had two kinds of tests, which I like to call programmer
> tests and customer tests. The customer tests, also called "acceptance
> tests", are "owned" by the XP Customer and when those tests work, the story
> is said to be done. The customer tests serve as examples of how the system
> is to behave, and serve as a kind of agreement on what's to be done that
> can side-step a lot of arguments about whether the story meant X or not.
> The convention is that if there isn't a customer test for X, then the story
> didn't mean X. We create a new story that tests for X and schedule it.
> Meanwhile we learn to think about X-like things when we define stories.
>
> So Customer tests / acceptance tests spawned the notion of ATDD,
> Acceptance Test Driven Development, by analogy to TDD. This is a fair
> analogy, in that tests precede building, but not a great one, because TDD
> tests are about discovering how to build something, and ATDD ones are not
> so much about that.
>

I don't agree with that statement about ATDD, as I have found it to be as
much about discovery as TDD is.

In 2000, I was working with an XP team in San Francisco doing something as
close to pure XP as was possible.  Kent Beck was consulting to the team
there.  Rob Mee of Pivotal was there.  Eric Evans was there and others.
One problem we encountered was that our on-site customers were not
producing the Customer tests fast enough.  With each and every new
iteration, we were falling behind on having Customer tests and automating
them.  We tried some techniques -- like letting the customers specify some
tests via MS Excel.  It helped a little, mostly for the financial

(Continue reading)

headers

JeffGrigg | 10 May 2012 00:06

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

--- RonJeffries <ronjeffries <at> ...> wrote:
> There was also the notion of the "Detroit School" of TDD and
> the "London School". I have no idea who came up with these
> names. The London school took a very isolationist approach,
> focused on testing a single object, plugging in mocks, stubs,
> and various kind of test doubles so as to test just one test
> at a time. We in the Detroit School just tested the system's
> behavior. We might use a mock object to disconnect from a
> database or something. We didn't use them as a matter of course. 

Hadn't heard the "London School" name.  The "each class must be tested in isolation by mocking everything
else" came to my attention via the ThoughtWorks Ashcroft project:  They wrote a Java security manager
class to enforce that your tests ***MUST NOT*** test more than a single application class in isolation.

ThoughtWorks is full of really smart and capable people.  But the "each class in complete isolation" thing
always struck me as kind of silly and pointless.  Misleading and a bad idea, in fact.  What if I refactor a
class to split it into two classes?  Do I have to rewrite the tests at the same time?  But some people seem to
think that it works well for them.

http://docs.codehaus.org/display/ASH/Home

"Ten Commandments of Unit Tests"
 1. I am the class being tested. Thou shalt not test any other class but me.
 2. Thou shalt write isolated tests
 3. Thou shalt not access files during unit tests
 4. Thou shalt not write two tests which depend upon each other"

[And I thought I had doubts about programmer's ability to count!!!]

> My guess is that it's still all the same elephant, and that

(Continue reading)

headers

extremeprogrammer | 10 May 2012 15:09

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

I believe it was Michael Feathers who came up with the "Detroit" (or "Chicago") name, in contrast to the
"London" School name which already seemed to exist.

--- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...> wrote:
>
> Hi Jeff,
> 
> On May 9, 2012, at 3:28 PM, Jeff Langr wrote:
> 

> There was also the notion of the "Detroit School" of TDD and the "London School". I have no idea who came up
with these names.

headers

Laurent Bossavit | 9 May 2012 22:48

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

And here is another attempt at pinning down BDD:
    http://guide.agilealliance.org/guide/bdd.html

headers

George Dinwiddie | 13 May 2012 21:44

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

Hi, Adam,

On 5/9/12 7:38 PM, Adam Sroka wrote:
> I have a philosophical problem with ATDD as I usually see it practiced
> in that I think the line between programmer and customer tests is
> blurrier than some insist it is. For example, is the very first
> Cucumber scenario you write a customer or programmer test? If you are
> following the principles then you must do the simplest thing that can
> work and add more tests to compel additional behavior. That means you
> *must* fake it at this point. However, if you fake it and the test
> passes have you really done what the customer expected? If not, can we
> really call this a customer test?

I don't know who you're watching, but that's not the way I approach 
ATDD. I'll write the expression of the customer's desire (perhaps using 
Cucumber and Given-When-Then), and often let that drive some of the API 
for interacting with the system. I don't use that, however, to drive the 
low-level functionality of the code. Instead, I switch to xUnit/xSpec 
frameworks to TDD/BDD to drive things from a programmer point of view.

I've seen some serious problems when people try to drive all the code 
from the Customer point of view. For the most part, it leads them to 
work in steps that are far too large.

> In other words, I think there is a cognitive dissonance between the
> principles of TDD and the intent of ATDD. I don't, in my own work, use
> anything other than xUnit/xSpec to write customer tests.

You can certainly do that. I noticed years ago that I was doing that in 
JUnit, and started segregating the customer tests (or requirements

(Continue reading)

headers

Adam Sroka | 13 May 2012 22:05

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

On Sun, May 13, 2012 at 12:44 PM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
>
>
>
> Hi, Adam,
>
> On 5/9/12 7:38 PM, Adam Sroka wrote:
> > I have a philosophical problem with ATDD as I usually see it practiced
> > in that I think the line between programmer and customer tests is
> > blurrier than some insist it is. For example, is the very first
> > Cucumber scenario you write a customer or programmer test? If you are
> > following the principles then you must do the simplest thing that can
> > work and add more tests to compel additional behavior. That means you
> > *must* fake it at this point. However, if you fake it and the test
> > passes have you really done what the customer expected? If not, can we
> > really call this a customer test?
>
> I don't know who you're watching, but that's not the way I approach
> ATDD. I'll write the expression of the customer's desire (perhaps using
> Cucumber and Given-When-Then), and often let that drive some of the API
> for interacting with the system. I don't use that, however, to drive the
> low-level functionality of the code. Instead, I switch to xUnit/xSpec
> frameworks to TDD/BDD to drive things from a programmer point of view.
>

Right. So, the way you do ATDD is not TDD at all. You switch to TDD in
order to design the actual system.

> I've seen some serious problems when people try to drive all the code

(Continue reading)

headers

George Dinwiddie | 15 May 2012 16:48

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

Adam,

On 5/13/12 10:05 PM, Adam Sroka wrote:
> On Sun, May 13, 2012 at 12:44 PM, George Dinwiddie
> <lists <at> idiacomputing.com>  wrote:
>>
>>
>>
>> Hi, Adam,
>>
>> On 5/9/12 7:38 PM, Adam Sroka wrote:
>>> I have a philosophical problem with ATDD as I usually see it practiced
>>> in that I think the line between programmer and customer tests is
>>> blurrier than some insist it is. For example, is the very first
>>> Cucumber scenario you write a customer or programmer test? If you are
>>> following the principles then you must do the simplest thing that can
>>> work and add more tests to compel additional behavior. That means you
>>> *must* fake it at this point. However, if you fake it and the test
>>> passes have you really done what the customer expected? If not, can we
>>> really call this a customer test?
>>
>> I don't know who you're watching, but that's not the way I approach
>> ATDD. I'll write the expression of the customer's desire (perhaps using
>> Cucumber and Given-When-Then), and often let that drive some of the API
>> for interacting with the system. I don't use that, however, to drive the
>> low-level functionality of the code. Instead, I switch to xUnit/xSpec
>> frameworks to TDD/BDD to drive things from a programmer point of view.
>>
>
> Right. So, the way you do ATDD is not TDD at all. You switch to TDD in

(Continue reading)

headers

Adam Sroka | 15 May 2012 18:09

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

On Tue, May 15, 2012 at 7:48 AM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
>
>
>
> Adam,
>
>
>
> On 5/13/12 10:05 PM, Adam Sroka wrote:
> > On Sun, May 13, 2012 at 12:44 PM, George Dinwiddie
> > <lists <at> idiacomputing.com> wrote:
> >>
> >>
> >>
> >> Hi, Adam,
> >>
> >> On 5/9/12 7:38 PM, Adam Sroka wrote:
> >>> I have a philosophical problem with ATDD as I usually see it practiced
> >>> in that I think the line between programmer and customer tests is
> >>> blurrier than some insist it is. For example, is the very first
> >>> Cucumber scenario you write a customer or programmer test? If you are
> >>> following the principles then you must do the simplest thing that can
> >>> work and add more tests to compel additional behavior. That means you
> >>> *must* fake it at this point. However, if you fake it and the test
> >>> passes have you really done what the customer expected? If not, can we
> >>> really call this a customer test?
> >>
> >> I don't know who you're watching, but that's not the way I approach
> >> ATDD. I'll write the expression of the customer's desire (perhaps using

(Continue reading)

headers

Charlie Poole | 13 May 2012 22:37

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

Hi George,

On Sun, May 13, 2012 at 12:44 PM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
>
>
>
> Hi, Adam,
>
> On 5/9/12 7:38 PM, Adam Sroka wrote:
> > I have a philosophical problem with ATDD as I usually see it practiced
> > in that I think the line between programmer and customer tests is
> > blurrier than some insist it is. For example, is the very first
> > Cucumber scenario you write a customer or programmer test? If you are
> > following the principles then you must do the simplest thing that can
> > work and add more tests to compel additional behavior. That means you
> > *must* fake it at this point. However, if you fake it and the test
> > passes have you really done what the customer expected? If not, can we
> > really call this a customer test?
>
> I don't know who you're watching, but that's not the way I approach
> ATDD. I'll write the expression of the customer's desire (perhaps using
> Cucumber and Given-When-Then), and often let that drive some of the API
> for interacting with the system. I don't use that, however, to drive the
> low-level functionality of the code. Instead, I switch to xUnit/xSpec
> frameworks to TDD/BDD to drive things from a programmer point of view.

Yes. This is what I do and teach as well.

> I've seen some serious problems when people try to drive all the code

(Continue reading)

headers

PAUL | 14 May 2012 06:39

Learning, continuity and the need for a enduring professional volcabulary

Ni All,

I've been watching this thread go on and an, and on.... Eventually being drawn back in simply because what
seems obvious to me wasn't clearly being expressed.

Having had ago myself it dawned on me that expressing what I mean wasn't so easy. Several terms where being
used for the same thing.

For example customers tests, requirements. Story tests, specification, functional tests, etc, are all
being used nterchnageabl to mean the same thing. Is ther any wonder ther is mass confusion?

Who is to blame? As an industry we are very immature. No more so then in our use of language. I hate it when
people choose to introduce new language to mean the same thing, simply to make a different emphasis.
Everyone is guilty of it. XP replacing requirements, with stories for example.

What it means is that we have become an industry with no history, no continuity. No shared learning that is
passed from one generation to the next. Instead we reinvent ourselves every 10 years or so.

I feel very sorry for people like M. Manca trying to make sense of it all. Ive seen many of these waves come and
go, so have an idea of the cronology, and even I can't make sense of it, never mind someone that is new to it all.

When people intentionally poor the same wine in new bottles, which seems the case with BDD is it any wonder
that other people become confused over the labels?

I feel a rant coming on. I just wanted to shift the conversation on to what I believe is the root cause here,
rather then just discussingf the symptoms.

Paul.

(Continue reading)

headers

Steven Gordon | 14 May 2012 07:24

Re: Learning, continuity and the need for a enduring professional volcabulary

There is no authority for software development terminology, let alone
within the agile space.

Maybe, our discipline is not mature enough for that yet (and may never be),
but a terminology police is not going to accelerate the maturing process.
 It might make the discipline seem more mature, but such an effort would
stifle innovation if it succeeded (which I would sincerely doubt, given the
lack of an authority and the number of different languages and development
environments/tools).

Sometimes people mistakenly say they are doing X because they do not know
what the terminology is really supposed to mean.  But, just as often,
people who agree on the terminologies are still not really doing X when
they say they are doing X because they are really trying to do X but are
failing to really do it right for one reason or another.  So, when somebody
says they are doing X, we will just have to ask them to tell us what they
are doing step by step.  It is not so bad, we will certainly learn more
about what is good and bad about what they are doing.

SteveG

On Sun, May 13, 2012 at 9:39 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

> **
>
>
>
> Ni All,
>
> I've been watching this thread go on and an, and on.... Eventually being

(Continue reading)

headers

Charlie Poole | 14 May 2012 08:05

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Paul,

I feel like solving the problem across the universe of software development
is beyond me, but perhaps there are a few small things we can do to
mitigate the problem as it occurs here.

1) Since this is the XP list, let's use XP terminology. Or if something
outside of XP is used, then relate it to the accepted XP terms. I think we
have a community of understanding around most such terms.

2) When someone uses one of those (few) terms which don't have a clear,
single definition in the community, let them know that is the case right
away. People who come here are generally quite intelligent and able to
handle a certain degree of ambiguity, but it doesn't help when those in the
know simply put forward competing definitions without clarifying that there
are differing, potentially valid points of view.

Every field has a few areas where there is some disagreement, including
much more established fields than ours. Part of being a professional is
having an awareness of where those disagreements lie and warning newcomers
about them. Ron did this when he explained to Massimo how there were two
threads of thought in the BDD community.

I think there is enough common understanding about most terminology we use
that the few that have competing interpretations can simply be noted.

Of course, this leaves the larger problem to which you refer, but let's not
let its apparent intractability stop us from doing what we can.

Charlie

(Continue reading)

headers

RonJeffries | 14 May 2012 08:17

Re: Learning, continuity and the need for a enduring professional volcabulary


On May 14, 2012, at 12:39 AM, PAUL wrote:

> [All being used interchangeably]

Not really ...

> For example customers tests,

tests owned by the customer, serving to check specific examples of correct system behavior;

> requirements.

things the product must do;

> Story tests,

tests serving to check specific examples for specific stories, owner unspecified;

> specification,

all the requirements;

> functional tests,

tests serving to check specific examples, story and owner unspecified;

> etc, are  [all being used nterchnageabl to mean the same thing]. Is ther any wonder ther is mass confusion?

Well, they don't look to be interchangeable to me. They appear to express different ideas, in a nuanced fashion.

(Continue reading)

headers

PAUL | 14 May 2012 10:00

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Ron,

This made me laugh :)

I beg to differ. My background is in telecommunications, and most in that profession would find our lack of
rigour laughable.

I guess when you've lived a thing for a very long time you begin to see it as normal. 

Take care,

Paul.

--- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...> wrote:
>
> 
> On May 14, 2012, at 12:39 AM, PAUL wrote:
> 
> > [All being used interchangeably]
> 
> Not really ...
> 
> > For example customers tests,
> 
> tests owned by the customer, serving to check specific examples of correct system behavior;
> 
> > requirements.
> 
> things the product must do;
>

(Continue reading)

headers

Joshua Kerievsky | 14 May 2012 08:26

Re: Learning, continuity and the need for a enduring professional volcabulary

On Sun, May 13, 2012 at 9:39 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

> For example customers tests, requirements. Story tests, specification,
> functional tests, etc, are  all being used nterchnageabl to mean the same
> thing. Is ther any wonder ther is mass confusion?
>

Have you heard of the term "microtest"?   To the best of my knowledge, Mike
Hill introduced it.  Now why would he do something like that when he
could've just used the term "unit test"?

Mike was coaching on numerous projects at various companies where people
were already writing unit tests.  The only problem was that their unit
tests tended to be giant gobs of code, 6 inches to 2 feet long!  This
happened on gig after gig.  He tried to re-wire their notion of what a unit
test is, but it didn't work.  They were just too used to what they meant by
the term unit test.  That's when Mike decided to be explicit with a new
term.  A microtest, he explained, is a short (few lines of code), isolated
(runs independently of other tests), fast-running, test that checks a
single behavior of a single class.

Was this useful?  Or did it just add to the confusion?

I've been using Mike's term for years now.  The term allows me to sidestep
the entire debate about what is or isn't a unit test.  We simply talk
microtests, teach how to write them and segue into how they are used in
TDD.

best
jk

(Continue reading)

headers

PAUL | 14 May 2012 10:20

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Joshua,

> I've been using Mike's term for years now.  The term allows me to sidestep
> the entire debate about what is or isn't a unit test.  We simply talk
> microtests, teach how to write them and segue into how they are used in
> TDD.
> 

Why sidestep the debate? Rather then reach consensus, through peer review and debate, just create a bunch
of new terminology? I wonder were that will lead?

To me it seems far too easy to invent new terms. There are good reasons sometimes. For example the idea of a
story does provide a different connotation to the idea of a requirement. So the cost of the new term could be
said to be worth the break in continuity with the body of knowledge associated with the old label of requirements.

I think there should be a bar for the introduction of new terminology. The fact that the existing
terminology is fuzzy isn't a reason to introduce yet more. We should be self critical and discuss at a meta
level like we are now, about whether a new term is indeed valuable, or whether it is just added to the noise.

Finally when we do introduce new vocabulary, we should at least try to define it with some rigour, citing
prior work and existing widely excepted terms to do so, as Charlie suggests.

This is common amongst most professions. The idea of introducing terminology on a whim is scorned upon by
most professionals, which is why they tend not to do it.

In our culture, it's the norm, and over the years, I've seen the bar for new terms get lower and lower, until
virtually any little nuance is reason enough to invent a whole new vocabulary of your own making and market
the heck out of it.

Paul.

(Continue reading)

headers

Dave Rooney | 14 May 2012 12:29

Re: Learning, continuity and the need for a enduring professional volcabulary

On 12-05-14 4:20 AM, PAUL wrote:
> Hi Joshua,
>
>> I've been using Mike's term for years now.  The term allows me to sidestep
>> the entire debate about what is or isn't a unit test.  We simply talk
>> microtests, teach how to write them and segue into how they are used in
>> TDD.
>>
> Why sidestep the debate? Rather then reach consensus, through peer review and debate, just create a bunch
of new terminology? I wonder were that will lead?
>
> To me it seems far too easy to invent new terms. There are good reasons sometimes. For example the idea of a
story does provide a different connotation to the idea of a requirement. So the cost of the new term could be
said to be worth the break in continuity with the body of knowledge associated with the old label of requirements.

A little while back I coached at a large telecom company, working with a 
team that was writing call processing software for wireless switches.  
They had boatloads of unit tests.  During the first sprint planning 
meeting I attended, the team wanted to add stories to the backlog for 
specific unit tests above and beyond what had been planned.

I was taken aback somewhat, so I asked them how long it took to write a 
unit test.  Their answer was "2 to 3 weeks per test".  From that point 
forward, we used the term "microtest" for the low-level behavioural 
tests they had started to write using GoogleTest and GoogleMock.

Within a few months, pretty well everyone I encountered was using 
"microtest", mainly because it had no baggage from prior use.

Dave...

(Continue reading)

headers

PAUL | 14 May 2012 14:32

Re: Learning, continuity and the need for a enduring professional volcabulary

 Hi Dave,

> Within a few months, pretty well everyone I encountered was using 
> "microtest", mainly because it had no baggage from prior use.
> 

Yes. The avoidance of prior package does have it's advantages. Microtest is a new term to me, so in this
discussion is a barrier to communication.

Of course i could look it up, but with a burgeoning vocabulary, learning all these new terms can become a big
hit on my time.

And that assumes that the explicit definitions are rigourous. In the example you describe here, your
audience had the advantage of you showing them by example, so they quickly got to know what you mean.

Written language isn't as powerful....

An alternative would be to say that your unit tests are too big, explain *why* too big is a bad idea, and *show
by example* as you did with "micorotests" what a good unit test looks like.

Wouldn't that have worked as well?

Paul.
> Dave...
> 
> -- 
> *Dave Rooney* | Agile Coach and Co-founder
> Westboro Systems <http://www.westborosystems.com/> - Agile Coaching, 
> Training, Organizational Transformation.
> Blog <http://practicalagility.blogspot.com> | Twitter

(Continue reading)

headers

Joshua Kerievsky | 14 May 2012 13:50

Re: Learning, continuity and the need for a enduring professional volcabulary

On Mon, May 14, 2012 at 1:20 AM, PAUL <beckfordp <at> btopenworld.com> wrote:

> Why sidestep the debate? Rather then reach consensus, through peer review
> and debate, just create a bunch of new terminology? I wonder were that will
> lead?
>

Terminology lives within a context.  Our context is lean/agile transitions.
 Our objective as coaches is to help folks improve people's skills as
rapidly as possible in order to make ourselves unnecessary as fast as
possible.  Any term that consistently stands in the way of that objective
must be dealt with. When a new term consistently solves a problem in our
context, we adopt it with vigor.  Microtest is such a term.  Using that
term has proven to be more effective than trying to gain consensus through
peer review and debate about what a proper unit test ought to be.

We introduce new terms carefully and sparingly in our context.

This is common amongst most professions. The idea of introducing
> terminology on a whim is scorned upon by most professionals, which is why
> they tend not to do it.

> In our culture, it's the norm, and over the years, I've seen the bar for
> new terms get lower and lower, until virtually any little nuance is reason
> enough to invent a whole new vocabulary of your own making and market the
> heck out of it.
>

Do you have examples of such new terms and evidence of how they were
created "on a whim"?

(Continue reading)

headers

MarvinToll.com | 14 May 2012 14:35

Re: Learning, continuity and the need for a enduring professional volcabulary

hmmm... this is a little tricky.

Is the "whim" associated with the content or the marketing term?

I have six years of emergent content I'm marketing on a "whim" term... "Software Agility".  And I
"whimsically" grouped together seven long-standing "illities" to support the term.  (
http://wp.me/P1FU3L-8B )

And some would argue (strongly) I'm contributing to industry confusion by the coupling of those two words. 
However, I think they grossly over-estimate my influence.

Said another way, "whimming" is fun.

_Marvin

--- In extremeprogramming <at> yahoogroups.com, Joshua Kerievsky <joshua <at> ...> wrote:
>
> On Mon, May 14, 2012 at 1:20 AM, PAUL <beckfordp <at> ...> wrote:
> 
> > In our culture, it's the norm, and over the years, I've seen the bar for
> > new terms get lower and lower, until virtually any little nuance is reason
> > enough to invent a whole new vocabulary of your own making and market the
> > heck out of it.
> >
> 
> Do you have examples of such new terms and evidence of how they were
> created "on a whim"?
> 
> best
> jk

(Continue reading)

headers

PAUL | 14 May 2012 14:26

Re: Learning, continuity and the need for a enduring professional volcabulary


Hi Joshua,

> Do you have examples of such new terms and evidence of how they were
> created "on a whim"?
> 

Evidence? Sounds very confrontational. I've got examples yes. The language of Domain Driven Design, Eric
Evans work. He comes up with new names for a number of ideas that had long been established in the field of OO
Modelling. I think his book would have been better if he had cited the work of people that came before him, 
like Shlaer-Mellor who had done a fair amount of prior work in this area, and had created a useful body of
knowledge and terminology which his work builds upon and could have/should have been reused.

I'm sure there are other examples, where the introduction of new language has created a great deal of confusion.

Regards,

Paul.
> best
> jk
> 
> 
> [Non-text portions of this message have been removed]
>

headers

M. Manca | 14 May 2012 14:40

Re: Learning, continuity and the need for a enduring professional volcabulary

Il 14/05/2012 14:26, PAUL ha scritto:
>  
>
>
> Hi Joshua,
>
> > Do you have examples of such new terms and evidence of how they were
> > created "on a whim"?
> >
>
> Evidence? Sounds very confrontational. I've got examples yes. The
> language of Domain Driven Design, Eric Evans work. He comes up with
> new names for a number of ideas that had long been established in the
> field of OO Modelling. I think his book would have been better if he
> had cited the work of people that came before him, like Shlaer-Mellor
> who had done a fair amount of prior work in this area, and had created
> a useful body of knowledge and terminology which his work builds upon
> and could have/should have been reused.
>
> I'm sure there are other examples, where the introduction of new
> language has created a great deal of confusion.
>
Dan North proposed BDD and its therminolgy as an answer to questions and
confusion he reported teaching TDD. What do you think about? Had he
clarified some ideas or had he put more confusion?
>
>
> Regards,
>
> Paul.

(Continue reading)

headers

PAUL | 14 May 2012 14:55

Re: Learning, continuity and the need for a enduring professional volcabulary


Hi,

> Dan North proposed BDD and its therminolgy as an answer to questions and
> confusion he reported teaching TDD. What do you think about? Had he
> clarified some ideas or had he put more confusion?
> >

I think Dan has been very explicit about his intent, and he makes numerous references to TDD. AFAIK he has
never claimed that BDD was something other than TDD/Customer Acceptance Tests. Just another way to think
about the same thing.

As Ron has mentioned, there is an alternate school of BDD, and for me the alternate school of Chris and Liz (if
indeed they themselves see it as an alternate) is somewhat confusing.

Im must admit they I have read little of their work, but I have seen people who do BDD the sort of way Ron describes.

Have they mis-understood? I don't know. I guess the only way for me to find out for sure would be to BDD with Liz
Keogh or Chris Matts, so that they could show me what they mean by example.

Paul.

headers

M. Manca | 14 May 2012 15:11

Re: Learning, continuity and the need for a enduring professional volcabulary

Il 14/05/2012 14:55, PAUL ha scritto:
>  
>
>
>
> Hi,
>
> > Dan North proposed BDD and its therminolgy as an answer to questions and
> > confusion he reported teaching TDD. What do you think about? Had he
> > clarified some ideas or had he put more confusion?
> > >
>
> I think Dan has been very explicit about his intent, and he makes
> numerous references to TDD. AFAIK he has never claimed that BDD was
> something other than TDD/Customer Acceptance Tests. Just another way
> to think about the same thing.
>
He said he would provide a better definition of BDD later, but in my
knowledge he didn't. So in my mind I use this scheme to think about:
there is a set of test-first disciplines, inside there are TDD and BDD
(and may other but I don't need them to clarify what I am writing) as 2
subsets, I think there is an intersection between them and BDD syntax
may be better understandable if used to write customer tests/acceptance
tests and TDD syntax is well done at developer level.

Personally I think that "customer acceptance test" may be a little
better notation because nobody can't misunderstand the scope and how has
the role to add/remove the test and verify if it passed or not. I don't
mean that the customer has to write the test alone, I mean he has the
last word about its meaning and to decide the pass condition is met.

(Continue reading)

headers

Charlie Poole | 14 May 2012 18:19

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Massimo,

<snip/>
> ...BDD syntax
> may be better understandable if used to write customer tests/acceptance
> tests and TDD syntax is well done at developer level.

I wrote it earlier, but I must object again!

There *is* no TDD syntax. TDD is done in a wide variety of languages
using a variety of tools. Each has its own syntax.

There is nothing in TDD that says I must use a certain syntax. That,
in fact, is what I see as one problem with BDD: it appears to dictate
a particular syntax as the only 'right' way to write tests.

Syntax in writing tests is much more driven by the language in which
the tests are written than anything else. As such, I think it's a very
poolr way to define a technique or methodology.

That's not to say that TDD doesn't have a common vocabulary, which
is sometimes drawn upon for the syntax of specific tools. Many tools
use the word 'test' for example and many of them perform 'asserts.'
But what is done 'commonly' isn't enough for a definition, IME.

Charlie

headers

M. Manca | 14 May 2012 18:40

Re: Learning, continuity and the need for a enduring professional volcabulary

Il 14/05/2012 18:19, Charlie Poole ha scritto:
>  
>
> Hi Massimo,
>
> <snip/>
> > ...BDD syntax
> > may be better understandable if used to write customer tests/acceptance
> > tests and TDD syntax is well done at developer level.
>
> I wrote it earlier, but I must object again!
>
> There *is* no TDD syntax. TDD is done in a wide variety of languages
> using a variety of tools. Each has its own syntax.
>
Yes,  it is not correct to say that TDD has its own syntax. There are
many unit (and not unit) test frameworks with their own rules to follow.
I think it was a cut and paste error. I would say that BDD syntax help
to write acceptance tests and every other tests could be used for tests
done at developer level. I hope developers write readable tests with
meaningful identifiers and so on.
>
>
> There is nothing in TDD that says I must use a certain syntax. That,
> in fact, is what I see as one problem with BDD: it appears to dictate
> a particular syntax as the only 'right' way to write tests.
>
Yes, I should say "suggest" more then "dictate" but I agree.
>
>

(Continue reading)

headers

Adam Sroka | 14 May 2012 18:42

Re: Learning, continuity and the need for a enduring professional volcabulary

I don't think this is fair. There have been a proliferation of TDD
frameworks based on xUnit, and there have also been a proliferation of BDD
frameworks based on xSpec. However, there are numerous variations of both
that take advantage of language specific features or idioms.

What is true is that the BDD folks have made a big deal about the *English*
semantics of testing and insisted that they be removed in favor of language
that favors specification.

A random thought about that: the first time you write the test it meets the
definition of a specification. However, as soon as you start running it and
making decisions based on the results it is meeting the first dictionary
definition of "test."

On Mon, May 14, 2012 at 9:19 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> **
>
>
> Hi Massimo,
>
> <snip/>
> > ...BDD syntax
>
> > may be better understandable if used to write customer tests/acceptance
> > tests and TDD syntax is well done at developer level.
>
> I wrote it earlier, but I must object again!
>
> There *is* no TDD syntax. TDD is done in a wide variety of languages

(Continue reading)

headers

Charlie Poole | 14 May 2012 18:59

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Adam,

Except for the first sentence, you appear to be agreeing with everything
I wrote - or at least with what I imagine my writing to mean. What
exactly is not fair?

On Mon, May 14, 2012 at 9:42 AM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
> I don't think this is fair. There have been a proliferation of TDD
> frameworks based on xUnit, and there have also been a proliferation of BDD
> frameworks based on xSpec. However, there are numerous variations of both
> that take advantage of language specific features or idioms.

Exactly my point. There is no single 'TDD syntax'.

> What is true is that the BDD folks have made a big deal about the *English*
> semantics of testing and insisted that they be removed in favor of language
> that favors specification.

Yes. A 'test' is a specification, but not merely a specification. Just
as a 'story' is
more than just a 'functional requirement.'

> A random thought about that: the first time you write the test it meets the
> definition of a specification. However, as soon as you start running it and
> making decisions based on the results it is meeting the first dictionary
> definition of "test."

BDD folks originally made quite a deal about the ambiguity of the word Test
and the confusing associations it brings. Apparently, they were less familiar
with the multiple meanings of 'Behavior'

(Continue reading)

headers

Adam Sroka | 14 May 2012 19:03

Re: Learning, continuity and the need for a enduring professional volcabulary

It is an oversimplification to say that there is a specific syntax for BDD
and not for TDD. There are common syntactic elements and significant
deviations depending on language/framework for both.

On Mon, May 14, 2012 at 9:59 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> **
>
>
> Hi Adam,
>
> Except for the first sentence, you appear to be agreeing with everything
> I wrote - or at least with what I imagine my writing to mean. What
> exactly is not fair?
>
>
> On Mon, May 14, 2012 at 9:42 AM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
> > I don't think this is fair. There have been a proliferation of TDD
> > frameworks based on xUnit, and there have also been a proliferation of
> BDD
> > frameworks based on xSpec. However, there are numerous variations of both
> > that take advantage of language specific features or idioms.
>
> Exactly my point. There is no single 'TDD syntax'.
>
>
> > What is true is that the BDD folks have made a big deal about the
> *English*
> > semantics of testing and insisted that they be removed in favor of
> language

(Continue reading)

headers

Charlie Poole | 14 May 2012 19:33

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Adam,

Right... what I meant is that BDD proponents seem to dictate syntax
in a way that I had not seen done before BDD. I didn't mean that each
of them calls for the same syntax.

AFAIK, nobody says "You have to use the word Assert to do TDD." But
BDD folks do have a tendency to require use of a particular syntax. So,
in spite of some degree of diversity, I think it may make more sense to
talk about BDD syntax than does TDD syntax.

Of course, it goes without saying that you have to correctly use the syntax
of any tool you choose to use. I'm thinking more about how we talk about
TDD/BDD and how we design those tools.

I may still be in a state of reaction to being told that failure to use the
word "should" proves I don't understand what tests are about. 

Charlie

On Mon, May 14, 2012 at 10:03 AM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
> It is an oversimplification to say that there is a specific syntax for BDD
> and not for TDD. There are common syntactic elements and significant
> deviations depending on language/framework for both.
>
> On Mon, May 14, 2012 at 9:59 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:
>
>> **
>>
>>

(Continue reading)

headers

George Dinwiddie | 15 May 2012 17:15

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi, Charlie,

On 5/14/12 6:19 PM, Charlie Poole wrote:
> There is nothing in TDD that says I must use a certain syntax. That,
> in fact, is what I see as one problem with BDD: it appears to dictate
> a particular syntax as the only 'right' way to write tests.

I'm not sure BDD dictates a particular syntax, either. My understanding 
is that BDD wanted to avoid the heavily loaded term "test" that seemed 
to cause much misunderstanding (especially at that time), and felt that 
a different terminology than "assert" would also be helpful.

I really think it's as simple as that. And I think that it will be a 
long time before we settle on a generally agreed terminology. We (as an 
industry) have yet to generally agree on what we find useful. These 
discussions about terminology are helpful, IMO, when we talk about the 
nuances of what we find useful, and why.

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

headers

Charlie Poole | 15 May 2012 17:46

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi George,

On Tue, May 15, 2012 at 8:15 AM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
>
>
>
> Hi, Charlie,
>
>
>
> On 5/14/12 6:19 PM, Charlie Poole wrote:
> > There is nothing in TDD that says I must use a certain syntax. That,
> > in fact, is what I see as one problem with BDD: it appears to dictate
> > a particular syntax as the only 'right' way to write tests.
>
> I'm not sure BDD dictates a particular syntax, either. My understanding
> is that BDD wanted to avoid the heavily loaded term "test" that seemed
> to cause much misunderstanding (especially at that time), and felt that
> a different terminology than "assert" would also be helpful.

As I wrote in a separate post, I should have said that each BDD person
I run into seems ready to dictate a particular syntax - although not the
same as any other BDD person. Perhaps it's because BDD is newer.
Perhaps it's because the movement is more closely coupled to tools.
Or perhaps I just talked to the wrong folks. 

> I really think it's as simple as that. And I think that it will be a
> long time before we settle on a generally agreed terminology. We (as an
> industry) have yet to generally agree on what we find useful. These

(Continue reading)

headers

George Dinwiddie | 15 May 2012 21:25

Re: Learning, continuity and the need for a enduring professional volcabulary

Charlie,

On 5/15/12 5:46 PM, Charlie Poole wrote:
> Hi George,
>
> On Tue, May 15, 2012 at 8:15 AM, George Dinwiddie
> <lists <at> idiacomputing.com>  wrote:
>>
>>
>>
>> Hi, Charlie,
>>
>>
>>
>> On 5/14/12 6:19 PM, Charlie Poole wrote:
>>> There is nothing in TDD that says I must use a certain syntax. That,
>>> in fact, is what I see as one problem with BDD: it appears to dictate
>>> a particular syntax as the only 'right' way to write tests.
>>
>> I'm not sure BDD dictates a particular syntax, either. My understanding
>> is that BDD wanted to avoid the heavily loaded term "test" that seemed
>> to cause much misunderstanding (especially at that time), and felt that
>> a different terminology than "assert" would also be helpful.
>
> As I wrote in a separate post, I should have said that each BDD person
> I run into seems ready to dictate a particular syntax - although not the
> same as any other BDD person. Perhaps it's because BDD is newer.
> Perhaps it's because the movement is more closely coupled to tools.
> Or perhaps I just talked to the wrong folks.

(Continue reading)

headers

Charlie Poole | 16 May 2012 02:07

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi George,

>>> On 5/14/12 6:19 PM, Charlie Poole wrote:
>>>> There is nothing in TDD that says I must use a certain syntax. That,
>>>> in fact, is what I see as one problem with BDD: it appears to dictate
>>>> a particular syntax as the only 'right' way to write tests.
>>>
>>> I'm not sure BDD dictates a particular syntax, either. My understanding
>>> is that BDD wanted to avoid the heavily loaded term "test" that seemed
>>> to cause much misunderstanding (especially at that time), and felt that
>>> a different terminology than "assert" would also be helpful.
>>
>> As I wrote in a separate post, I should have said that each BDD person
>> I run into seems ready to dictate a particular syntax - although not the
>> same as any other BDD person. Perhaps it's because BDD is newer.
>> Perhaps it's because the movement is more closely coupled to tools.
>> Or perhaps I just talked to the wrong folks. 
>
> Which tools are you talking about? To be honest, when I played with C#
> and NUnit some years back, I used the rspec-ish syntax (which I
> associated with BDD) over the junit-ish syntax.

My first intro to BDD was in the days of jBehave. The person explaining it
to me told me my personal view of testing was fatally flawed because I didn't
talk about 'should'. It still rankles, probably more than I should let it, and
may keep me from seeing the good in the movement - although I already
pointed out what I see as important contributions it has made.

'nuff said 'bout that I think.

(Continue reading)

headers

RonJeffries | 16 May 2012 02:30

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Charlie,

On May 15, 2012, at 8:07 PM, Charlie Poole wrote:

> I'm interested in your reference to the 'rspec-ish' NUnit syntax. I'm assuming
> you mean Assert.That(...) together with the various constraints. When I first
> wrote it back in 2007, my main influences were Joe Walnes assertThat
> libary, which later became Hamcrest and the syntax used in NMock2 for
> matching arguments to methods. It doesn't seem to be a syntax that most
> BDD folks like, although there are other syntaxes on top of NUnit that do
> implement the context/specification and given/when/then syntaxes.

I confess that I don't like it either, and for the same reason I don't like most of the given when thingies: I
can't read them easily as programming statements. The fact that they are like English doesn't help me.
They aren't English, they don't have its flexibility, and they're hard to read as programming.

I'm old-fashioned, I guess. I'm perfectly happy with assertEquals etc.

Ron Jeffries
www.XProgramming.com
Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

[Non-text portions of this message have been removed]

headers

Charlie Poole | 16 May 2012 03:39

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Ron,

On Tue, May 15, 2012 at 5:30 PM, RonJeffries <ronjeffries <at> acm.org> wrote:
>
>
>
> Hi Charlie,
>
>
>
> On May 15, 2012, at 8:07 PM, Charlie Poole wrote:
>
> > I'm interested in your reference to the 'rspec-ish' NUnit syntax. I'm assuming
> > you mean Assert.That(...) together with the various constraints. When I first
> > wrote it back in 2007, my main influences were Joe Walnes assertThat
> > libary, which later became Hamcrest and the syntax used in NMock2 for
> > matching arguments to methods. It doesn't seem to be a syntax that most
> > BDD folks like, although there are other syntaxes on top of NUnit that do
> > implement the context/specification and given/when/then syntaxes.
>
> I confess that I don't like it either, and for the same reason I don't like most of the given when thingies: I
can't read them easily as programming statements. The fact that they are like English doesn't help me.
They aren't English, they don't have its flexibility, and they're hard to read as programming.
>
> I'm old-fashioned, I guess. I'm perfectly happy with assertEquals etc.

That's why it's good to have a choice of tools or for a tool like
NUnit to give a choice of syntaxes. As I have said before, I didn't
implement the NUnit fluent syntax because I liked it, but because some
folks wanted it. I did learn to like it in the end though.

(Continue reading)

headers

MarvinToll.com | 16 May 2012 14:03

Re: Learning, continuity and the need for a enduring professional volcabulary

Lambdas are available with Java 8 - ( http://jdk8.java.net/lambda/ )

Using a (very) broad brush for the Java world... we have seen with the last three releases a complete API for
multi-core (concurrent) processing and now the emphasis has shifted to providing a useful subset of
functional programming capabilities.

As an aside, Java 10 (2017) may become fully OO... that is, no primitives. (
http://www.javaworld.com/javaworld/jw-03-2012/120315-oracle-s-java-roadmap.html )

--- In extremeprogramming <at> yahoogroups.com, Charlie Poole <charliepoole <at> ...> wrote:
>
> The 'coming thing' in the .NET world seems to be replacing all this
> extra syntax with use of lambdas, allowing C# programmers to write
> their constraints in C#, VBers in VB, etc.
> 
> Charlie
>

headers

JeffGrigg | 16 May 2012 22:11

Re: Learning, continuity and the need for a enduring professional volcabulary

In the Java world, we wish we had LINQ.  And Lambdas.  But some of that is more convenience than substance. 
We've had anonymous inner classes in Java for some time; aside from the really cluttered and inconvenient
syntax, they work mostly like lambdas.

I'm not expecting much of a "sea change" to come from the Java enhancements mentioned.  Sure, they'll be
nice.  But did LINQ and PLINKQ turn the .NET community into a multi-processing paradise?  [Hardly.]

I'm using the Gosu language heavily.  And it isn't the only language on the JVM that already provides lambdas
and bulk processing methods on collections.  Such things are very convenient, and they improve productivity.

But we will need more than that to make good use of the multi-core hardware that is being delivered already.

OpenJDK
"JEP 107: Bulk Data Operations for Collections"
http://openjdk.java.net/jeps/107

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> Lambdas are available with Java 8 - ( http://jdk8.java.net/lambda/ )
>
> Using a (very) broad brush for the Java world... we have seen
> with the last three releases a complete API for multi-core
> (concurrent) processing and now the emphasis has shifted to
> providing a useful subset of functional programming capabilities.

> --- Charlie Poole <charliepoole <at> > wrote:
>> The 'coming thing' in the .NET world seems to be replacing
>> all this extra syntax with use of lambdas, allowing C#
>> programmers to write their constraints in C#, VBers in VB, etc.

(Continue reading)

headers

MarvinToll.com | 17 May 2012 14:26

Re: Learning, continuity and the need for a enduring professional volcabulary

A trivial thought occurring during my daily ten-mile bike ride yesterday...

It was 26 years (1959 - 1985) for COBOL to stabilize with the release of COBOL 85.

Oracle has mapped a release schedule of Java through 2021 with JDK 12... Precisely 26 years (since 1995).

_Marvin

* Being unaware if Martin Fowler has provided a definition of "stable" software I'm using my own...
http://wp.me/P1FU3L-cl 
--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> wrote:
>
> In the Java world, we wish...

headers

JeffGrigg | 19 May 2012 11:09

Re: Learning, continuity and the need for a enduring professional volcabulary

I guess we're going to conveniently ignore COBOL 2002.

http://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> It was 26 years (1959 - 1985) for COBOL to stabilize with
> the release of COBOL 85.
> 
> Oracle has mapped a release schedule of Java through 2021
> with JDK 12... Precisely 26 years (since 1995).

And yes, "Java is the new COBOL."

>;->

headers

MarvinToll.com | 19 May 2012 12:32

Re: Learning, continuity and the need for a enduring professional volcabulary

I don't know about convenience... but ignoring Object-Oriented COBOL was deliberate on my part.

There are at least a couple of perspectives:

One. That OO COBOL was not really a maturation of the original 1959 design intent... but was a new language
leveraging the old platform... abstractly similar to the newer Functional Programming languages that
leverage the JVM.

Two.  That OO COBOL was not durably embraced by the global IT community... and that many wanting an OO
language moved on to something else.

Three.  The existence of OO COBOL does not automatically constitute a "maturing" of the language.  

[All that was said without having ever used OO COBOL... so I'm open other perspectives... or, perhaps Java
will continue to mature until 2038?)

--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> wrote:
>
> I guess we're going to conveniently ignore COBOL 2002.
> 
> http://en.wikipedia.org/wiki/COBOL#COBOL_2002_and_object-oriented_COBOL
> 
> 
> --- "MarvinToll.com" <MarvinToll <at> > wrote:
> > It was 26 years (1959 - 1985) for COBOL to stabilize with
> > the release of COBOL 85.
> > 
> > Oracle has mapped a release schedule of Java through 2021
> > with JDK 12... Precisely 26 years (since 1995).
>

(Continue reading)

headers

JeffGrigg | 19 May 2012 12:36

Re: Learning, continuity and the need for a enduring professional volcabulary

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 <at> ...> 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.

headers

M. Manca | 19 May 2012 12:44

Re: Re: Learning, continuity and the need for a enduring professional volcabulary

Il 19/05/2012 12:36, JeffGrigg ha scritto:
>  
>
> And how many programmers using a COBOL 85 compiler are writing code
> that is much different than just COBOL 64?
>
I wrote I think not more then 3 programs with Cobol during my first
employment to modify some legacy code related to printer and terminals.
If it is on the market I have a lot of possibility to use C/C++ until my
retirement .
>
>
> My observation has been "not many."
>
> (based on, admittedly, relatively few data points)
>
> --- "MarvinToll.com" <MarvinToll <at> ...> 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. 
>
> 

[Non-text portions of this message have been removed]

(Continue reading)

headers

MarvinToll.com | 19 May 2012 18:41

Re: Learning, continuity and the need for a enduring professional volcabulary

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 <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> 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 <at> > 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.

(Continue reading)

headers

George Dinwiddie | 16 May 2012 16:46

Re: Learning, continuity and the need for a enduring professional volcabulary

Charlie,

On 5/16/12 2:07 AM, Charlie Poole wrote:
> I'm interested in your reference to the 'rspec-ish' NUnit syntax. I'm assuming
> you mean Assert.That(...) together with the various constraints. When I first
> wrote it back in 2007, my main influences were Joe Walnes assertThat
> libary, which later became Hamcrest and the syntax used in NMock2 for
> matching arguments to methods. It doesn't seem to be a syntax that most
> BDD folks like, although there are other syntaxes on top of NUnit that do
> implement the context/specification and given/when/then syntaxes.

Yes, that. While it didn't say "should," it seemed more natural and 
convenient to use those matchers after using rspec for awhile. But I've 
been slow to pick up Hamcrest in Java for some reason. I guess I just 
haven't done enough to make it worth changing habits.

George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

headers

Charlie Poole | 16 May 2012 18:10

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi George,

On Wed, May 16, 2012 at 7:46 AM, George Dinwiddie
<lists <at> idiacomputing.com> wrote:
>
>
>
> Charlie,
>
>
>
> On 5/16/12 2:07 AM, Charlie Poole wrote:
> > I'm interested in your reference to the 'rspec-ish' NUnit syntax. I'm assuming
> > you mean Assert.That(...) together with the various constraints. When I first
> > wrote it back in 2007, my main influences were Joe Walnes assertThat
> > libary, which later became Hamcrest and the syntax used in NMock2 for
> > matching arguments to methods. It doesn't seem to be a syntax that most
> > BDD folks like, although there are other syntaxes on top of NUnit that do
> > implement the context/specification and given/when/then syntaxes.
>
> Yes, that. While it didn't say "should," it seemed more natural and
> convenient to use those matchers after using rspec for awhile. But I've
> been slow to pick up Hamcrest in Java for some reason. I guess I just
> haven't done enough to make it worth changing habits.

I think it's perfectly reasonable to have personal habits and idiosyncracies,
so long as those things needing to be standardized across a team get
standardized. Higher levels of standardization (company, community)
are of secondary benefit IMO.

(Continue reading)

headers

George Dinwiddie | 17 May 2012 10:32

Re: Learning, continuity and the need for a enduring professional volcabulary

Charlie,

On 5/16/12 6:10 PM, Charlie Poole wrote:
> I think it's perfectly reasonable to have personal habits and idiosyncracies,
> so long as those things needing to be standardized across a team get
> standardized. Higher levels of standardization (company, community)
> are of secondary benefit IMO.
>
> Ideally, I'd want a test framework that allows the team to trivially create a
> syntactic overlay that meets their own needs. This seems like a workable
> goal and a better one than trying to come up with the syntax that beats
> all others, for all purposes.

Exactly right, in my opinion.

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

headers

MarvinToll.com | 17 May 2012 13:45

Re: Learning, continuity and the need for a enduring professional volcabulary


This sounds like inheritance to me.

> On 5/16/12 6:10 PM, Charlie Poole wrote:
> >
> > Ideally, I'd want a test framework that allows the team to trivially create a
> > syntactic overlay that meets their own needs. This seems like a workable
> > goal and a better one than trying to come up with the syntax that beats
> > all others, for all purposes.
> 
> Exactly right, in my opinion.
> 
>   - George

headers

Charlie Poole | 17 May 2012 17:11

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Marvin,

On Thu, May 17, 2012 at 4:45 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com> wrote:
>
>
>
>
> This sounds like inheritance to me.

It could be, provided that the relevant parts of the framework are (1)
user-accessible
and (2) designed to be inherited from.

As a first cut at defining "trivial" in this context, I would suggest:

1) The user does not need to modify any parts of the framework, just
extend them.

2) The user does not need to extend parts of the framework that are not normally
  used in tests.

In the case of NUnit, for example, the portion normally used in tests comprises
about 10% of the code base (off the top of my head). So all desired syntax
recognition and handling would need to be (re)located in that portion of code.
I don't consider it "trivial" to develop an NUnit addin, which is what
you must now
do to define a new type of fixture. It would be trivial, if you could
do it by extending
the TestFixture attribute. For JUnit, the names are different, but the
idea is the same.

(Continue reading)

headers

MarvinToll.com | 17 May 2012 18:47

Re: Learning, continuity and the need for a enduring professional volcabulary


Perhaps I'm not understanding how to make this complicated?

Here are three representative convenience assert methods for persistence using JUnit v. 3 that seem
straight-forward to me?

public abstract class SjpBaseIncontainerTestCase extends
        SjcBaseIncontainerTestCase {

    /**
     * This method ensures instances were persisted.
     * 
     *  <at> param persistenceSI
     *  <at> param instances
     */
    protected void assertPersisted(final SjcPiPersistenceSI persistenceSI,
            final SjcBaseBO... instances) {

        // Declare/Initialize
        int numberOfInstances = 0;

        System.out.println("\n\t*** Begin Persisted Assertion ***; thread="
                + Thread.currentThread().getName() + "\n");

        final long startTime = System.nanoTime();

        for (final SjcBaseBO instance : instances) {

            if (!persistenceSI.exists(instance)) {

(Continue reading)

headers

Charlie Poole | 17 May 2012 20:02

Re: Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Marvin,

Convenience assert methods are easy to write in almost every framework.

We were talking about an entire syntactic overlay, not just a single assert.

"Trivial" for me would mean that pretty much anyone with the
skills needed to use the framework would be able to extend it - not
just the reigning guru on a particular team

Suppose, for example, I want to create a type of test class that runs all
the tests in parallel, with facilities for coordination among them. I'd like
to express that by adding a ParallellFixture attribute to the class.

This is doable in NUnit but not trivial. It's doable in JUnit by creating a
runner and using it - still what I'd call a non-trivial operation.

That's the case for most current frameworks for static languages. But it
could be made easy - even  trivial - by thoughtful design of the framework.

I know that several other tool-builders are also thinking this way.

Charlie

On Thu, May 17, 2012 at 9:47 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
>

(Continue reading)

headers

Adrian Howard | 17 May 2012 20:36

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Charlie,

On 16 May 2012, at 17:10, Charlie Poole wrote:
[snip]
> Ideally, I'd want a test framework that allows the team to trivially create a
> syntactic overlay that meets their own needs. This seems like a workable
> goal and a better one than trying to come up with the syntax that beats
> all others, for all purposes.
[snip]

This is one of the reasons I *really* like Perl's testing framework - it has exactly this sort of setup.

It's evolved so everything produces and consumes TAP (http://testanything.org/) a simple
human-readable protocol for expressing pass/fail results (with standard modules that help people
output and consume TAP).

This means I can write tests procedurally, or in an xUnit style, or a BDD style, or a specification-based
testing style, or use various DSLs for things like exception testing or for testing web apps... and so on. 

I just use the style that seems most appropriate for the thing being tested. They all output TAP. All the
standard test runners consume TAP. Everything "just works" and plays nice together.

I can even easily integrate tests running in other languages or environments as long as they output TAP.

In addition - since almost all of the Perl testing modules use a common TAP output module - you can usually
integrate different styles in the same test code. So, if appropriate, I can pop some specification-based
tests and some friendly web-testing DSL as assertions inside my xUnit tests. Fun 

Wish other languages test environments were setup this way.

(Continue reading)

headers

Adrian Howard | 14 May 2012 14:54

Re: Learning, continuity and the need for a enduring professional volcabulary

On 14 May 2012, at 13:26, PAUL wrote:

> Evidence? Sounds very confrontational. I've got examples yes. The language of Domain Driven Design,
Eric Evans work. He comes up with new names for a number of ideas that had long been established in the field
of OO Modelling. I think his book would have been better if he had cited the work of people that came before
him, like Shlaer-Mellor who had done a fair amount of prior work in this area, and had created a useful body
of knowledge and terminology which his work builds upon and could have/should have been reused.

Like?

DDD seems interestingly different from the Shlaer-Mellor method in the same way that "stories" are
interestingly different from what most people call "requirements".

Builds on - kinda... sorta... But the resulting technique as a whole is quite different. The focus on
translation for example is mostly absence in DDD, as is the focus on modelling with finite-state
machines. The patternish stuff in DDD is pretty much absent from Shlaer-Mellor. And so on...

I think you would confuse more than you would help by using the same terms. Especially as swapping in the few
terms that are pretty much 1-2-1 matches would remove the unity of the language that Evans' uses to
describe DDD.

You could make the same argument that DDD came from Wirf-Brock's RDD or Reenskaug Role Modeling. To be frank
the fact that the names of (very smart) folk like Shlaer-Mellor, Wirf-Brock & Reenskaug aren't as
familiar as they should be says something about the way those ideas are being communicated.

(Actually DDD is a fave example of mine when talking about cross-disciplinary stuff. For example there's
stuff in OOAD, IA, & Content Strategy - which all "sort of" look like DDD from a certain perspective. Yet
they've all come from very different places, are aimed at very different audiences, and are part of a
different language and dialog. Aren't communities of practice fun!)

(Continue reading)

headers

PAUL | 14 May 2012 15:03

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Adrian,

An interesting point of view. I agree that Erics book covers much more then Schlaer-Mellor, for the size of
it you would expect it to :)

I agree that he comes at it with a different feel, but I don't think that stops you making citations back to
prior work.

it's interesting that you have made the links for yourself. Probably because you were familiar with the
prior work.

I know people who found Erics book difficult to understand, and have been helped by reading the prior work,
after I suggested it and provided references.

Paul.

--- In extremeprogramming <at> yahoogroups.com, Adrian Howard <adrianh <at> ...> wrote:
>
> 
> On 14 May 2012, at 13:26, PAUL wrote:
> 
> > Evidence? Sounds very confrontational. I've got examples yes. The language of Domain Driven Design,
Eric Evans work. He comes up with new names for a number of ideas that had long been established in the field
of OO Modelling. I think his book would have been better if he had cited the work of people that came before
him,  like Shlaer-Mellor who had done a fair amount of prior work in this area, and had created a useful body
of knowledge and terminology which his work builds upon and could have/should have been reused.
> 
> Like?
> 
> DDD seems interestingly different from the Shlaer-Mellor method in the same way that "stories" are

(Continue reading)

headers

Charlie Poole | 14 May 2012 18:06

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Paul

On Mon, May 14, 2012 at 6:03 AM, PAUL <beckfordp <at> btopenworld.com> wrote:
>
>
>
> Hi Adrian,
>
> An interesting point of view. I agree that Erics book covers much more then Schlaer-Mellor, for the size of
it you would expect it to :)
>
> I agree that he comes at it with a different feel, but I don't think that stops you making citations back to
prior work.
>
> it's interesting that you have made the links for yourself. Probably because you were familiar with the
prior work.
>
> I know people who found Erics book difficult to understand, and have been helped by reading the prior work,
after I suggested it and provided references.

I think we're a tad off the topic here: Eric decided to write a
particular type of book, long on how-to and short on references in
your view. I imagine that his book, re-written to be chock-full of
references to past work, might not have sold quite so many copies.
Nevertheless, he defines his terms quite well and the book stands by
itself.

Charlie

(Continue reading)

headers

Joshua Kerievsky | 14 May 2012 15:12

Re: Learning, continuity and the need for a enduring professional volcabulary

On Mon, May 14, 2012 at 5:26 AM, PAUL <beckfordp <at> btopenworld.com> wrote:

> Evidence? Sounds very confrontational.

I'm simply not aware of how you could tell if someone created a new term
after careful consideration or on a whim.

> I've got examples yes. The language of Domain Driven Design, Eric Evans
> work. He comes up with new names for a number of ideas that had long been
> established in the field of OO Modelling. I think his book would have been
> better if he had cited the work of people that came before him,  like
> Shlaer-Mellor who had done a fair amount of prior work in this area, and
> had created a useful body of knowledge and terminology which his work
> builds upon and could have/should have been reused.
>

He runs an email list on DDD.  You might ask him whether he knew the work
of Shlaer-Mellor and if so, why he elected not to use their terms.  Eric's
a great guy - he might even write about their work or form some
associations to his work or improve his manuscript for a 2nd edition.

One thing is sure though: Eric didn't create any new terms in his book on a
whim.  He carefully thought about his pattern language and developed that
language on real software projects for years prior to writing about it.  I
know this from first-hand experience working with Eric, shepherding his
early pattern language on DDD and meeting in cafes to write our books
together and swap feedback.

I'm sure there are other examples, where the introduction of new language
> has created a great deal of confusion.

(Continue reading)

headers

PAUL | 14 May 2012 15:29

Re: Learning, continuity and the need for a enduring professional volcabulary

hi Joshua,

I can't tell anyone's whims :) Bad choice of words. It would be nice to see more citations and some
justification for introducing new language I guess :|

Yes. There is a long list of areas that could do with attention. We are talking about it which is good.

Paul.

--- In extremeprogramming <at> yahoogroups.com, Joshua Kerievsky <joshua <at> ...> wrote:
>
> On Mon, May 14, 2012 at 5:26 AM, PAUL <beckfordp <at> ...> wrote:
> 
> > Evidence? Sounds very confrontational.
> 
> 
> I'm simply not aware of how you could tell if someone created a new term
> after careful consideration or on a whim.
> 
> 
> > I've got examples yes. The language of Domain Driven Design, Eric Evans
> > work. He comes up with new names for a number of ideas that had long been
> > established in the field of OO Modelling. I think his book would have been
> > better if he had cited the work of people that came before him,  like
> > Shlaer-Mellor who had done a fair amount of prior work in this area, and
> > had created a useful body of knowledge and terminology which his work
> > builds upon and could have/should have been reused.
> >
> 
> He runs an email list on DDD.  You might ask him whether he knew the work

(Continue reading)

headers

PAUL | 15 May 2012 04:01

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Joshua,

I've been thinking abut your list:

> 
> Acceptance test
> Regression test
> Integration test
> Customer test
> Storytest
> 
> It would probably be helpful to explore how those terms came about, how
> they differ (if at all).
> 

Then it struck me that this is the role Martin Fowler tends to fill with his Bliki. A clearing house for
terminology, linking our past with our present, tying together related ideas, by introducing
consistent terminology, and creating a unified language around which people can discuss the future.

Martin gets the importance of language and how it can either help or hinder thinking, both at an indvidual
and community level.

Should we formalise this role? Should we officially make it Martins job? Or should it be the responsibility
of a committee of the great and the good?

Coming back to telecommunications, the ITU is the international body responsible for
telecommunications standards. This is an umbrella for a number of affiliated organisations that work at
the national level. They take responsibility to act as a professional standards body.

Do we need this type of structure too? I sense that there is an anarchic tendency in the software industry. Is

(Continue reading)

headers

Charlie Poole | 14 May 2012 17:57

Re: Learning, continuity and the need for a enduring professional volcabulary

Hi Paul,

> > I've been using Mike's term for years now. The term allows me to sidestep
> > the entire debate about what is or isn't a unit test. We simply talk
> > microtests, teach how to write them and segue into how they are used in
> > TDD.
> >
>
> Why sidestep the debate? Rather then reach consensus, through peer review and debate, just create a bunch
of new terminology? I wonder were that will lead?

Sticking with this single example, I have to say that you seem to have
missed Joshua's point. The rapidity with which many of us have adopted
'micro-test' is simply an indication of the long-standing problem with
misinterpretations of the term 'unit test.' I was writing 'unit tests'
in the 70s, and I can assure you they didn't look much like what we
call unit tests in XP. That's a source of confusion, particularly for
traditionally trained testers, where the 'unit' is often a single
binary module.

When Hill first suggested the term 'micro-test', people in the
community immediately saw what he was trying to do and why. Adoption
has now spread widely enough that I can use the term - here and in
other Agile contexts - and expect to be understood by knowledgable
people. In other contexts, I still have to explain it.

Perhaps that's also an important point: you're posting and reading in
the context of the XP community.

Charlie

(Continue reading)

headers

George Dinwiddie | 15 May 2012 16:58

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

Charlie,

On 5/13/12 10:37 PM, Charlie Poole wrote:
> Hi George,
>
> On Sun, May 13, 2012 at 12:44 PM, George Dinwiddie
> <lists <at> idiacomputing.com>  wrote:
>>
>>
>>
>> Hi, Adam,
>>
>> On 5/9/12 7:38 PM, Adam Sroka wrote:
>>> I have a philosophical problem with ATDD as I usually see it practiced
>>> in that I think the line between programmer and customer tests is
>>> blurrier than some insist it is. For example, is the very first
>>> Cucumber scenario you write a customer or programmer test? If you are
>>> following the principles then you must do the simplest thing that can
>>> work and add more tests to compel additional behavior. That means you
>>> *must* fake it at this point. However, if you fake it and the test
>>> passes have you really done what the customer expected? If not, can we
>>> really call this a customer test?
>>
>> I don't know who you're watching, but that's not the way I approach
>> ATDD. I'll write the expression of the customer's desire (perhaps using
>> Cucumber and Given-When-Then), and often let that drive some of the API
>> for interacting with the system. I don't use that, however, to drive the
>> low-level functionality of the code. Instead, I switch to xUnit/xSpec
>> frameworks to TDD/BDD to drive things from a programmer point of view.
>

(Continue reading)

headers

Charlie Poole | 15 May 2012 17:57

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

Hi George,

<snip/>

> Thanks for your thoughtful reply. I think there's very little difference
> in our points of view, though we express it a little differently.

I agree.

Charlie

headers

PAUL | 13 May 2012 22:41

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

Hi George,

This is spot on. AT is about requirements and expression those requirements through tests (examples). TDD
is about Design and expressing a design idea through tests.

Where BDD has gone wrong I think, is that it has focused on tooling and the use of languages (s DSL), but
forgotten to talk about requirements, design and tests.

For those with a solid background in all three concepts, then the new language is a useful convenience. Nice
but not necessary.

For those without a solid understanding of these fundamental concepts the tooling and the language has
become an ends in themselves I find.

I hate mentioning software engineering, but there was a time when knowing the difference between
validation (requirements tests) and verification (design tests) was common knowledge amongst
programmers. This is no longer the case. Instead programmers know all about cucumber, spec etc, but
little lesson. Schooled through blogs... :)

An understanding of the distinction between requirements through example and design through example has
been mostly lost,,. leading to a hybrid validation/verification approach that bears no resemblance to
TDD and doesn't work in my experience.

I keep thinking we need to go back to basics, but my basics are a foreign language to many who are new to
programming in the last 5 years or so.

Developers use to have a wall of books, that explained the "basics", most never read them, but at least they
had them :) Now, people seldom read books, and the classics on analysis and design have mostly been
forgotten. For instance Mellir Page-Jones is still my classic reference even today when it comes to
coupling and cohesion:.

(Continue reading)

headers

Adam Sroka | 13 May 2012 22:53

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

These are all good points. I agree that it CAN be done, but that it takes
an understanding of design and requirements to use it effectively.

I also agree that the focus on tooling has been a distraction, and that is
chiefly what I am complaining about.

I have seen many teams adopt Scrum and fail to get traction because they
implement all the ceremonies but miss the intent. I see the adoption of
ATDD, and particularly tool driven approaches to ATDD, as having similar
pitfalls.

On Sun, May 13, 2012 at 1:41 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

> **
>
>
> Hi George,
>
> This is spot on. AT is about requirements and expression those
> requirements through tests (examples). TDD is about Design and expressing a
> design idea through tests.
>
> Where BDD has gone wrong I think, is that it has focused on tooling and
> the use of languages (s DSL), but forgotten to talk about requirements,
> design and tests.
>
> For those with a solid background in all three concepts, then the new
> language is a useful convenience. Nice but not necessary.
>
> For those without a solid understanding of these fundamental concepts the

(Continue reading)

headers

PAUL | 14 May 2012 00:19

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


+1

--- In extremeprogramming <at> yahoogroups.com, Adam Sroka <adam.sroka <at> ...> wrote:
>
> These are all good points. I agree that it CAN be done, but that it takes
> an understanding of design and requirements to use it effectively.
> 
> I also agree that the focus on tooling has been a distraction, and that is
> chiefly what I am complaining about.
> 
> I have seen many teams adopt Scrum and fail to get traction because they
> implement all the ceremonies but miss the intent. I see the adoption of
> ATDD, and particularly tool driven approaches to ATDD, as having similar
> pitfalls.
> 
> 
> On Sun, May 13, 2012 at 1:41 PM, PAUL <beckfordp <at> ...> wrote:
> 
> > **
> >
> >
> > Hi George,
> >
> > This is spot on. AT is about requirements and expression those
> > requirements through tests (examples). TDD is about Design and expressing a
> > design idea through tests.
> >
> > Where BDD has gone wrong I think, is that it has focused on tooling and
> > the use of languages (s DSL), but forgotten to talk about requirements,

(Continue reading)

headers

George Dinwiddie | 15 May 2012 17:35

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

Paul,

On 5/13/12 10:41 PM, PAUL wrote:
> Hi George,
>
> This is spot on. AT is about requirements and expression those
> requirements through tests (examples). TDD is about Design and
> expressing a design idea through tests.
>
> Where BDD has gone wrong I think, is that it has focused on tooling
> and the use of languages (s DSL), but forgotten to talk about
> requirements, design and tests.

I think BDD has done no such thing. Perhaps you have focused on that and 
associated it with BDD.

> For those with a solid background in all three concepts, then the new
> language is a useful convenience. Nice but not necessary.

I'm not even sure which "language" you mean. Are you talking about "it 
should" or "Given When Then" or something else?

> For those without a solid understanding of these fundamental concepts
> the tooling and the language has become an ends in themselves I
> find.

That sounds like prejudice, to me. You're talking about some large group 
of people that you can dismiss as being inferior because they don't have 
the "solid understanding of these fundamental concepts" that you have.

(Continue reading)

headers

PAUL | 15 May 2012 18:29

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

George,

--- In extremeprogramming <at> yahoogroups.com, George Dinwiddie <lists <at> ...> wrote:
>
> Paul,
> 
> On 5/13/12 10:41 PM, PAUL wrote:
> > Hi George,
> >
> > This is spot on. AT is about requirements and expression those
> > requirements through tests (examples). TDD is about Design and
> > expressing a design idea through tests.
> >
> > Where BDD has gone wrong I think, is that it has focused on tooling
> > and the use of languages (s DSL), but forgotten to talk about
> > requirements, design and tests.
> 
> I think BDD has done no such thing. Perhaps you have focused on that and 
> associated it with BDD.

I agree, that's a gross over generalization. Having said that I am aware of books on BDD tools (Cucumber,
Rspec). No books on BDD itself. In contrast there are several books on TDD, distinct from the tooling.
> 
> > For those with a solid background in all three concepts, then the new
> > language is a useful convenience. Nice but not necessary.
> 
> I'm not even sure which "language" you mean. Are you talking about "it 
> should" or "Given When Then" or something else?
>

(Continue reading)

headers

George Dinwiddie | 15 May 2012 21:39

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

Paul,

On 5/15/12 6:29 PM, PAUL wrote:
> George,
>
> --- In extremeprogramming <at> yahoogroups.com, George Dinwiddie<lists <at> ...>  wrote:
>>
>> Paul,
>>
>> On 5/13/12 10:41 PM, PAUL wrote:
>>> Hi George,
>>>
>>> This is spot on. AT is about requirements and expression those
>>> requirements through tests (examples). TDD is about Design and
>>> expressing a design idea through tests.
>>>
>>> Where BDD has gone wrong I think, is that it has focused on tooling
>>> and the use of languages (s DSL), but forgotten to talk about
>>> requirements, design and tests.
>>
>> I think BDD has done no such thing. Perhaps you have focused on that and
>> associated it with BDD.
>
> I agree, that's a gross over generalization. Having said that I am
> aware of books on BDD tools (Cucumber, Rspec). No books on BDD
> itself. In contrast there are several books on TDD, distinct from the
> tooling.

Perhaps that says that BDD is *more* tool agnostic. Certainly the 
languages of Cucumber and Rspec are very different.

(Continue reading)

headers

George Dinwiddie | 15 May 2012 22:19

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

Paul,

On 5/15/12 9:39 PM, George Dinwiddie wrote:
>>>> So yes, ATDD can work quite well if you know what you're doing.  That
>>>> is if you know the difference between customer tests and design tests
>>>> first (or last :)) If you don't, then it's just another distraction.
>>>
>>> What things are helpful when you don't know what you're doing?
>>
>> A good teacher, with the time and patience to show you by example. If
>> you can't find that then a good book full of examples  (like TDD by
>> Example by Kent Beck).. I find google and blogs a poor substitute for
>> either of the above.
>
> I think the Cucumber book, and Goyko's Specification By Example, give
> some good examples. They're not quite as detailed and low-level as TDD
> By Example, but they're good books.

You might also be interested in ATDD By Example (http://amzn.to/Kdkyt3) 
by Markus Gartner, due out in July. I've not read the final text of this 
book, but I can recommend it from the draft I read. It seems like just 
the book you're asking for.

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org

(Continue reading)

headers

PAUL | 16 May 2012 01:18

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


Hi George, 
--- In extremeprogramming <at> yahoogroups.com, George Dinwiddie <lists <at> ...> wrote:
>
> Paul,
> 
> On 5/15/12 9:39 PM, George Dinwiddie wrote:
> >>>> So yes, ATDD can work quite well if you know what you're doing.  That
> >>>> is if you know the difference between customer tests and design tests
> >>>> first (or last :)) If you don't, then it's just another distraction.
> >>>
> >>> What things are helpful when you don't know what you're doing?
> >>
> >> A good teacher, with the time and patience to show you by example. If
> >> you can't find that then a good book full of examples  (like TDD by
> >> Example by Kent Beck).. I find google and blogs a poor substitute for
> >> either of the above.
> >
> > I think the Cucumber book, and Goyko's Specification By Example, give
> > some good examples. They're not quite as detailed and low-level as TDD
> > By Example, but they're good books.
> 
> You might also be interested in ATDD By Example (http://amzn.to/Kdkyt3) 
> by Markus Gartner, due out in July. I've not read the final text of this 
> book, but I can recommend it from the draft I read. It seems like just 
> the book you're asking for.
> 

Thanks for the book recommendations. I've visited Goyko's website and thought yes!  I must get his book. I'm
not anti-BDD. I use BDD by choice when it comes to customer tests, and I am indifferent, BDD or TDD, when it

(Continue reading)

headers

MarvinToll.com | 10 May 2012 02:37

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

Sounds like we may have some anecdotal meat to chew on...

Charlie... could you elborate or annotate or referenciate?

--- In extremeprogramming <at> yahoogroups.com, Charlie Poole <charliepoole <at> ...> wrote:
>
> The two biggest contributions of BDD to (at least my) TDD have been
> * The notion of organizing tests by a context
> * The importance of syntax in testing tools
> 
> Charlie
>

headers

Charlie Poole | 10 May 2012 06:41

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

Sure...

1. Context/Specification style BDD originated the use of the term "context"
to describe
the situation as it should exist before executing a test makes sense. It's
approximately
the same as the Given in Given/When/Then style BDD and as Arrange in the
standard 3As of TDD. In straight xUnit Unit testing, the Context is often
called the Fixture.

Experienced TDDers have always taught that the Context/Fixture should be
used as
an organizing principle for test methods and that it should be based on the
logical
state of the application rather than simple one-to-one mapping to the
classes under
test. BDD folk made that much more explicit in the early years of BDD and I
believe
they made it easier for TDDers like me to get our message across.

Translating this to my own terminology, which looks suspiciously like
NUnit's, I would
say "Organize your tests into Fixtures, such that each test requires the
same SetUp
because they all deal with the same state of the application (Context). For
more
info, google BDD context specification.

2. Traditionally, tool-builders for TDD didn't worry much about making the
syntax

(Continue reading)

headers

Charlie Poole | 9 May 2012 18:14

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

Hi,

On Wed, May 9, 2012 at 8:46 AM, M. Manca <m.manca <at> micronengineering.it> wrote:
>
>
>
> Il 09/05/2012 17:23, Charlie Poole ha scritto:
>
>
> > Hi,
> >
> > I think you may have misunderstood me - and perhaps Ron as well.
> May be I misunderstood you, more or less my idea wasn't to be who of us
> is right or find an universal definition about what is BDD and what is
> not. I admitted from the beginning that I have a difficulty to tell what
> I think because there are too much terms to say more or less the same
> thing in a half dozen ways.

I don't think we're having a discussion where it's possible for somebody to
be right or wrong - we're talking about what we do. Right?

> >
> > I'm pretty familiar with the history of BDD and have read much of what you
> > list
> > there. I have tried several so-called BDD tools and like some of them for
> > some
> > purposes.
> Of course I didn't copy and paste for this reason, I was only surprised
> to read so many different interpretations. May be that some times a more
> formal definition of BDD may define better its boundaries.

(Continue reading)

headers

M. Manca | 9 May 2012 18:25

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

Il 09/05/2012 18:14, Charlie Poole ha scritto:
> Hi,
>
> On Wed, May 9, 2012 at 8:46 AM, M. Manca <m.manca <at> micronengineering.it> wrote:
>>
>>
>> Il 09/05/2012 17:23, Charlie Poole ha scritto:
>>
>>
>>> Hi,
>>>
>>> I think you may have misunderstood me - and perhaps Ron as well.
>> May be I misunderstood you, more or less my idea wasn't to be who of us
>> is right or find an universal definition about what is BDD and what is
>> not. I admitted from the beginning that I have a difficulty to tell what
>> I think because there are too much terms to say more or less the same
>> thing in a half dozen ways.
> I don't think we're having a discussion where it's possible for somebody to
> be right or wrong - we're talking about what we do. Right?
Yes.
>
>>> I'm pretty familiar with the history of BDD and have read much of what you
>>> list
>>> there. I have tried several so-called BDD tools and like some of them for
>>> some
>>> purposes.
>> Of course I didn't copy and paste for this reason, I was only surprised
>> to read so many different interpretations. May be that some times a more
>> formal definition of BDD may define better its boundaries.
>> I think that XP is better defined, it is more clear what is and what

(Continue reading)

headers

Kay A Pentecost | 11 May 2012 00:33

RE: Re: Facts for incremental value of BDD? (Beyond TDD)

Hi, Everybody,

I'd really like somebody to write those paragraphs, and one on what they
mean by ATDD.  I've done a lot of TDD -- I write everything I can (and some
things I probably can't) test-driven, but BDD seems more higher level to
me... and I'd like to understand it more.

Kay Pentecost

> -----Original Message-----
> From: extremeprogramming <at> yahoogroups.com
> [mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of RonJeffries
> Sent: Tuesday, May 08, 2012 7:50 AM
> To: extremeprogramming <at> yahoogroups.com
> Subject: Re: [XP] Re: Facts for incremental value of BDD? (Beyond TDD)
> 
<snip>
> 
> 
> 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.
> 
> Ron Jeffries

headers

M. Manca | 11 May 2012 11:16

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

After some hours of mumble mumble I will try in alphabetic order:

ATDD:
Acceptance Test Driven Development is the practice of expressing
functional story requirements as concrete examples (expectations) in
advance of user story development.

BDD:
Behaviordriven development is about implementing an application by describing its behaviour from the
perspective of its stakeholders.
For this reason it puts some emphasis to remove the word test from the
BDD dictionary preferring user stories and scenarios. Also it gives more
attention to the syntax used to write user requirements using a business
oriented language and to translate them in executable requirements.

TDD:
Test Driven Development is the practice that follows test-first
programming concept, it put more emphasis on the repetition of a very
short development cycle base on an initial failing test written first,
then defining/writing a minimum piece of code to pass the initial test
followed by a refactoring phase that hasn't to break the just passed test.

The general ideas I have about them:
All of them are based on the test first principle, the difference is
related to the different points of view.

TDD is a practice made by developers to use by themselves so the
terminology it is good if the audience are other developers and it was a
newer approach to do our daily work with more fun and with more results.
In my opinion it was a bottom-up practice or a bottom growing practice

(Continue reading)

headers

Charlie Poole | 11 May 2012 18:37

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

Hi,

It's interesting that ATDD as you have defined it (and I think you have it
right)
is pretty much exactly the XP practice called "Customer Tests" or earlier
"Acceptance Tests."

And TDD is the XP practice "Test-Driven Development."

I'll deal with BDD later.

In XP, it has always been quite clear that we don't choose between doing
TDD
and ATDD... they are just two of the practices that you have to do, if you
want
to do XP. I think this is quite important - in or out of XP - because there
exists
a (relatively small) group of people who claim you don't need unit tests. I
think
you do in all but the most trivial applications.

Whether you choose to use the same tool for developer and customer tests
or a different tool is a matter for the individual project. I do think it's
important
for a developer to know whether an indivual test is a customer test or a
developer test. The distinction is quiet clear: a developer can always
change
the success criterion for a developer test, without consulting anyone else;
only
the Customer can change a customer test.

(Continue reading)

headers

Joshua Kerievsky | 11 May 2012 19:00

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

On Fri, May 11, 2012 at 9:37 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> It's interesting that ATDD as you have defined it (and I think you have it
> right)
> is pretty much exactly the XP practice called "Customer Tests" or earlier
> "Acceptance Tests."
>

Huh?!?   ATDD stands for Acceptance TEST-DRIVEN DEVELOPMENT.  What am I
missing, other than my email to this group seems to have fallen on silent
ears.   --jk

[Non-text portions of this message have been removed]

headers

Charlie Poole | 11 May 2012 19:20

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

Hi Joshua,

Well, it also stands for ACCEPTANCE TEST-Driven Development!

Could you explain why you don't think ATDD matches the Acceptance /
Customer Test practice?

Charlie

On Fri, May 11, 2012 at 10:00 AM, Joshua Kerievsky <
joshua <at> industriallogic.com> wrote:

> **
>
>
> On Fri, May 11, 2012 at 9:37 AM, Charlie Poole <charliepoole <at> gmail.com
> >wrote:
>
>
> > It's interesting that ATDD as you have defined it (and I think you have
> it
> > right)
> > is pretty much exactly the XP practice called "Customer Tests" or earlier
> > "Acceptance Tests."
> >
>
> Huh?!? ATDD stands for Acceptance TEST-DRIVEN DEVELOPMENT. What am I
> missing, other than my email to this group seems to have fallen on silent
> ears. --jk
>

(Continue reading)

headers

Joshua Kerievsky | 11 May 2012 19:29

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

On Fri, May 11, 2012 at 10:20 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> Well, it also stands for ACCEPTANCE TEST-Driven Development!
>
> Could you explain why you don't think ATDD matches the Acceptance /
> Customer Test practice?
>

Here's how I see ATDD (which we called Storytest-Driven Development):
http://industrialxp.org/storyTdd.html

If that doesn't help, I'll explain more.  There is also a link to a paper
on that page, which explains it in depth.

best
jk

[Non-text portions of this message have been removed]

headers

Charlie Poole | 11 May 2012 19:40

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

Hi Joshua,

Looking at the diagram, it seems like you use "Storytest-Driven
Development" to
encompass both customer tests and unit tests. That is, I see the traditional
TDD cycle with unit tests within a box in the same diagram. Is that an
accurate
reflection of your terminology?

To my knowledge, most people talking about ATDD seem to treat traditional
TDD
as a separate thing. I could be wrong, of course, and it really doesn't
matter since
it's just a matter of terminology. However, that's why I (a) equated ATDD
to the
Customer Test practice and (b) didn't talk about your STDD. STDD seems more
like an amalgamation of several practices than a single practice.

Do you not agree that the traditional Customer Test practice of XP taught us
to (at least) define the customer test before working on the story? That's
certainly how I learned it.

Charlie

On Fri, May 11, 2012 at 10:29 AM, Joshua Kerievsky <
joshua <at> industriallogic.com> wrote:

> **
>
>

(Continue reading)

headers

Joshua Kerievsky | 11 May 2012 19:53

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

On Fri, May 11, 2012 at 10:40 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> Looking at the diagram, it seems like you use "Storytest-Driven
> Development" to
> encompass both customer tests and unit tests. That is, I see the
> traditional
> TDD cycle with unit tests within a box in the same diagram. Is that an
> accurate
> reflection of your terminology?
>
> To my knowledge, most people talking about ATDD seem to treat traditional
> TDD
> as a separate thing. I could be wrong, of course, and it really doesn't
> matter since
> it's just a matter of terminology. However, that's why I (a) equated ATDD
> to the
> Customer Test practice and (b) didn't talk about your STDD. STDD seems more
> like an amalgamation of several practices than a single practice.
>
> Do you not agree that the traditional Customer Test practice of XP taught
> us
> to (at least) define the customer test before working on the story? That's
> certainly how I learned it.
>

The traditional Customer Test practice didn't suggest automating a failing
test and driving development from that failing test.

To me, we have Storytelling (telling the story of what you want and
composing it as a User Story), Storytesting (coming up with examples that

(Continue reading)

headers

Charlie Poole | 11 May 2012 20:51

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

Hi Joshua,

I think it's a question of focus. It's true that working from a failing
customer test was not explicit in the original practices, but I think it's
strongly implied.

The relation between testing customer intent and developer intent is
complex enough that Kent wrote this about customer tests in 'Explained':

"I haven't figured out a way to synchronize the tests and the code in the
same way that the code and the unit tests are synchronized. So, while the
measure of the unit tests is binary - 100% or bust - the measure of
functional tests is by necessity based on percentages. Over time you expect
the functional test scores to rise to near 100%." (p. 118)

So while Kent wasn't sure how to "synchronize" the tests, the implication
to me was always that they should be written in advance.

My biggest influence in thinking about customer versus developer tests came
from Ward, back in 2004 when we coded our way around Northern Italy. We
were both intent on exploring the relationship between customer and
developer tests and when/how you knew to switch your thinking between the
two domains. That's when the idea of starting with a failing customer test
really became a focus for me.

In fact, a lot of people were wondering about that issue at the time,
including you IIRC.  I think that driving development from Customer
tests became an explicit part of XP around that time, but I can't prove it.

BTW, none of this discussion was about SDD originally. Personally, I like

(Continue reading)

headers

Joshua Kerievsky | 11 May 2012 22:09

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

On Fri, May 11, 2012 at 11:51 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> My biggest influence in thinking about customer versus developer tests came
> from Ward, back in 2004 when we coded our way around Northern Italy. We
> were both intent on exploring the relationship between customer and
> developer tests and when/how you knew to switch your thinking between the
> two domains. That's when the idea of starting with a failing customer test
> really became a focus for me.
>
> In fact, a lot of people were wondering about that issue at the time,
> including you IIRC.  I think that driving development from Customer
> tests became an explicit part of XP around that time, but I can't prove it.
>

Here's an email to the XP list from April, 2003 in which I called SDD
"Customer Test-Driven Development":
http://tech.groups.yahoo.com/group/extremeprogramming/message/71589

By that time, I had enough confidence in this practice to go public with
it.  As I said in an earlier email, I'd been doing it for a few years
before 2003, on a variety of projects.

> BTW, none of this discussion was about SDD originally.

I think you were late to this idea, so it's funny to hear you make such
pronouncements.

best
jk

(Continue reading)

headers

RonJeffries | 11 May 2012 22:15

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

Hi Joshua,

On May 11, 2012, at 4:09 PM, Joshua Kerievsky wrote:

> I think you were late to this idea, so it's funny to hear you make such
> pronouncements.

Let's just assume that you invented everything that Kent didn't. I can live with that.

Ron Jeffries
www.XProgramming.com
Everything that needs to be said has already been said.
But since no one was listening, everything must be said again. -- Andre Gide

[Non-text portions of this message have been removed]

headers

Joshua Kerievsky | 11 May 2012 22:50

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

On Fri, May 11, 2012 at 1:15 PM, RonJeffries <ronjeffries <at> acm.org> wrote:

> Let's just assume that you invented everything that Kent didn't. I can
> live with that.
>

Does that mean I get to say I created "Card, Conversation, Confirmation"
too?     --jk

[Non-text portions of this message have been removed]

headers

RonJeffries | 11 May 2012 23:15

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

Sure, go for it :)
R
On May 11, 2012, at 4:50 PM, Joshua Kerievsky wrote:

> Does that mean I get to say I created "Card, Conversation, Confirmation"
> too?  --jk

Ron Jeffries
www.XProgramming.com
I'm really pissed off by what people are passing off as "agile" these days.
You may have a red car, but that does not make it a Ferrari.
  -- Steve Hayes

[Non-text portions of this message have been removed]

headers

Jeff Langr | 11 May 2012 23:32

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

Cripes, it's a pain to keep up with proper attributions.  Oh well, source
changed:
http://agileinaflash.blogspot.com/2009/03/card-conversation-confirmation.html

Jeff

Langr Software Solutions
http://langrsoft.com
http://agileinaflash.com <http://agileinaflash.com--/>

On Fri, May 11, 2012 at 3:15 PM, RonJeffries <ronjeffries <at> acm.org> wrote:

> Sure, go for it :)
> R
> On May 11, 2012, at 4:50 PM, Joshua Kerievsky wrote:
>
> > Does that mean I get to say I created "Card, Conversation, Confirmation"
> > too?  --jk
>
>
> Ron Jeffries
> www.XProgramming.com
> I'm really pissed off by what people are passing off as "agile" these days.
> You may have a red car, but that does not make it a Ferrari.
>  -- Steve Hayes
>
>
>
> [Non-text portions of this message have been removed]
>

(Continue reading)

headers

Charlie Poole | 11 May 2012 23:15

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

Hi Joshua,

On Fri, May 11, 2012 at 1:09 PM, Joshua Kerievsky
<joshua <at> industriallogic.com> wrote:
>
>
>
> On Fri, May 11, 2012 at 11:51 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:
>
>
>
> > My biggest influence in thinking about customer versus developer tests came
> > from Ward, back in 2004 when we coded our way around Northern Italy. We
> > were both intent on exploring the relationship between customer and
> > developer tests and when/how you knew to switch your thinking between the
> > two domains. That's when the idea of starting with a failing customer test
> > really became a focus for me.
> >
> > In fact, a lot of people were wondering about that issue at the time,
> > including you IIRC.  I think that driving development from Customer
> > tests became an explicit part of XP around that time, but I can't prove it.
> >
>
> Here's an email to the XP list from April, 2003 in which I called SDD
> "Customer Test-Driven Development":
> http://tech.groups.yahoo.com/group/extremeprogramming/message/71589
>
> By that time, I had enough confidence in this practice to go public with
> it. As I said in an earlier email, I'd been doing it for a few years
> before 2003, on a variety of projects.

(Continue reading)

headers

M. Manca | 11 May 2012 23:21

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

Il 11/05/2012 23:15, Charlie Poole ha scritto:
> Hi Joshua,
>
> On Fri, May 11, 2012 at 1:09 PM, Joshua Kerievsky
> <joshua <at> industriallogic.com> wrote:
>>
>>
>> On Fri, May 11, 2012 at 11:51 AM, Charlie Poole <charliepoole <at> gmail.com>wrote:
>>
>>
>>
>>> My biggest influence in thinking about customer versus developer tests came
>>> from Ward, back in 2004 when we coded our way around Northern Italy. We
>>> were both intent on exploring the relationship between customer and
>>> developer tests and when/how you knew to switch your thinking between the
>>> two domains. That's when the idea of starting with a failing customer test
>>> really became a focus for me.
>>>
>>> In fact, a lot of people were wondering about that issue at the time,
>>> including you IIRC.  I think that driving development from Customer
>>> tests became an explicit part of XP around that time, but I can't prove it.
>>>
>> Here's an email to the XP list from April, 2003 in which I called SDD
>> "Customer Test-Driven Development":
>> http://tech.groups.yahoo.com/group/extremeprogramming/message/71589
>>
>> By that time, I had enough confidence in this practice to go public with
>> it. As I said in an earlier email, I'd been doing it for a few years
>> before 2003, on a variety of projects.
> I'm not sure why you're disagreeing with me then... as I said, that was

(Continue reading)

headers

Charlie Poole | 11 May 2012 23:23

Subject: Re: Re: Facts for incremental value of BDD? (Beyond TDD)

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

Well, you didn't tell us before. 

At least now we have a definition of you. 

Charlie

On Fri, May 11, 2012 at 2:21 PM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>
>
> Il 11/05/2012 23:15, Charlie Poole ha scritto:
>
> > Hi Joshua,
> >
> > On Fri, May 11, 2012 at 1:09 PM, Joshua Kerievsky
> > <joshua <at> industriallogic.com> wrote:
> >>
> >>
> >> On Fri, May 11, 2012 at 11:51 AM, Charlie Poole <charliepoole <at> gmail.com
> >wrote:
> >>
> >>
> >>
> >>> My biggest influence in thinking about customer versus developer tests
> came
> >>> from Ward, back in 2004 when we coded our way around Northern Italy. We
> >>> were both intent on exploring the relationship between customer and
> >>> developer tests and when/how you knew to switch your thinking between
> the

(Continue reading)

headers

Joshua Kerievsky | 11 May 2012 23:26

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

On Fri, May 11, 2012 at 2:15 PM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> I'm not sure why you're disagreeing with me then... as I said, that was
> "around" the time it became a prominent part of XP. If you're looking to
> have your own role in it confirmed, I think that goes without saying.
>
> Frankly, this seems to be degenerating into some discussion of
> "who invented it" which wasn't what this thread was about at all.

I entered the thread when I started to hear stuff about ATDD that just
wasn't correct.  It's always been an emergent practice, exactly like TDD,
only at a higher level.  I mentioned my history with it to describe how we
practiced it back then.

If you mean (as I suspect) that I got into XP later than you, that's
> entirely
> correct. I got in after Beck, Jeffries and hundreds of other people as
> well.
>

I was referring to ATDD.

best
jk

[Non-text portions of this message have been removed]

headers

Charlie Poole | 11 May 2012 23:43

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

Hi Joshua,

On Fri, May 11, 2012 at 2:26 PM, Joshua Kerievsky
<joshua <at> industriallogic.com> wrote:
>
>
>
> On Fri, May 11, 2012 at 2:15 PM, Charlie Poole <charliepoole <at> gmail.com>wrote:
>
>
>
> > I'm not sure why you're disagreeing with me then... as I said, that was
> > "around" the time it became a prominent part of XP. If you're looking to
> > have your own role in it confirmed, I think that goes without saying.
> >
> > Frankly, this seems to be degenerating into some discussion of
> > "who invented it" which wasn't what this thread was about at all.
>
> I entered the thread when I started to hear stuff about ATDD that just
> wasn't correct. It's always been an emergent practice, exactly like TDD,
> only at a higher level. I mentioned my history with it to describe how we
> practiced it back then.

In that case, we seem to be trying to say the same thing. You'll note that
I didn't disagree with your post about your experience, but with some
things that other people said.

I still don't think we needed the extra acronyms, that's all.

>

(Continue reading)

headers

Joshua Kerievsky | 12 May 2012 03:00

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

On Fri, May 11, 2012 at 2:43 PM, Charlie Poole <charliepoole <at> gmail.com>wrote:

> In that case, we seem to be trying to say the same thing. You'll note that
> I didn't disagree with your post about your experience, but with some
> things that other people said.
>
> I still don't think we needed the extra acronyms, that's all.
>

Fair enough.

> In that case, I'm stunned that you would make such a comment, absent any
> knowledge of what I do or don't do. FWIW, I never say I do ATDD, because
> I really dislike the acronym. That said, I've been doing what most people
> call
> 'ATDD' for a long time. If it's not as long as you, it still isn't 'late'
> by my
> understanding, it was 'just in time.'
>

Sorry - I've been in an awful mood due to lack of sleep (woken by our
youngest at 4am) and having lower back pain.

I wish the community had some clarity on these practices that supplement
TDD.  Or maybe someone already clarified it and I'm not aware of their
work.

best
jk

(Continue reading)

headers

Adam Sroka | 12 May 2012 03:11

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

On Fri, May 11, 2012 at 6:00 PM, Joshua Kerievsky
<joshua <at> industriallogic.com> wrote:
>
> I wish the community had some clarity on these practices that supplement
> TDD. Or maybe someone already clarified it and I'm not aware of their
> work.
>

In some ways our terminology is better than the software community in
general. In other ways our terminology would have a hard time sucking
worse.

It still seems to me that very few outside of our inner circle really
grok what TDD is all about. It also seems that the proliferation of
xDD type names – sometimes in a snide and/or derisive way, although I
don't believe either the BDD or ATDD folks are guilty of that –
muddies the waters.

headers

Charlie Poole | 12 May 2012 03:26

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

The problem with the xDD names is that each of them sounds like it should
describe a whole methodological approach, rather than a single practice.

Charlie

On Fri, May 11, 2012 at 6:11 PM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
> On Fri, May 11, 2012 at 6:00 PM, Joshua Kerievsky
> <joshua <at> industriallogic.com> wrote:
>>
>> I wish the community had some clarity on these practices that supplement
>> TDD. Or maybe someone already clarified it and I'm not aware of their
>> work.
>>
>
> In some ways our terminology is better than the software community in
> general. In other ways our terminology would have a hard time sucking
> worse.
>
> It still seems to me that very few outside of our inner circle really
> grok what TDD is all about. It also seems that the proliferation of
> xDD type names – sometimes in a snide and/or derisive way, although I
> don't believe either the BDD or ATDD folks are guilty of that –
> muddies the waters.
>
>
> ------------------------------------
>
> To Post a message, send it to:   extremeprogramming <at> eGroups.com
>
> To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

(Continue reading)

headers

Adam Sroka | 12 May 2012 03:57

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

Right. Even TDD itself isn't just one practice but a synergism between
at least three: test-first programming, simple design, and merciless
refactoring.

On Fri, May 11, 2012 at 6:26 PM, Charlie Poole <charliepoole <at> gmail.com> wrote:
> The problem with the xDD names is that each of them sounds like it should
> describe a whole methodological approach, rather than a single practice.
>
> Charlie
>
> On Fri, May 11, 2012 at 6:11 PM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
>> On Fri, May 11, 2012 at 6:00 PM, Joshua Kerievsky
>> <joshua <at> industriallogic.com> wrote:
>>>
>>> I wish the community had some clarity on these practices that supplement
>>> TDD. Or maybe someone already clarified it and I'm not aware of their
>>> work.
>>>
>>
>> In some ways our terminology is better than the software community in
>> general. In other ways our terminology would have a hard time sucking
>> worse.
>>
>> It still seems to me that very few outside of our inner circle really
>> grok what TDD is all about. It also seems that the proliferation of
>> xDD type names – sometimes in a snide and/or derisive way, although I
>> don't believe either the BDD or ATDD folks are guilty of that –
>> muddies the waters.
>>
>>

(Continue reading)

headers

extremeprogrammer | 13 May 2012 00:42

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

Having been involved in the c2.com discussions about XP in 1999, I recall people talking about "acceptance
criteria" which were then cast into automated acceptance tests as a prelude to implementing a story.

Since that is the case, I actually find much of the excitement about A-TDD curious, since it did seem to be an
assumed part of the XP way when I first learned about XP.

Regards,

Lance

--- In extremeprogramming <at> yahoogroups.com, Charlie Poole <charliepoole <at> ...> wrote:
>
> Hi Joshua,
> 
> I think it's a question of focus. It's true that working from a failing
> customer test was not explicit in the original practices, but I think it's
> strongly implied.
>

headers

Adam Sroka | 13 May 2012 00:55

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

Largish teams, particularly those that have a separate but dedicated QA
team, have taken to ATDD because with a bit of training it allows them to
successfully use the QA team in the shorter timeframes demanded by their
new "Agile" overlords.

My main problem with this is that big teams with dedicated but separate QA
are not even close to the best way to organize a software development
effort.

ATDD is not a bad practice per se. However, ATDD is popular in part because
it is being practiced badly by a number of organizations that don't really
know what they are doing.

On Sat, May 12, 2012 at 3:42 PM, extremeprogrammer <LanceWalton <at> mac.com>wrote:

> **
>
>
> Having been involved in the c2.com discussions about XP in 1999, I recall
> people talking about "acceptance criteria" which were then cast into
> automated acceptance tests as a prelude to implementing a story.
>
> Since that is the case, I actually find much of the excitement about A-TDD
> curious, since it did seem to be an assumed part of the XP way when I first
> learned about XP.
>
> Regards,
>
> Lance
>

(Continue reading)

headers

RonJeffries | 13 May 2012 01:40

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

Hi Lance,

On May 12, 2012, at 6:42 PM, extremeprogrammer wrote:

> Since that is the case, I actually find much of the excitement about A-TDD curious, since it did seem to be an
assumed part of the XP way when I first learned about XP.

Customer tests, as they were called, were certainly around.

There are people who think to use product-level tests to "drive" something -- I'm not sure just what -- in a
way that is analogous to the way that microscopic programmer tests can be used to drive design. I would
suppose that's what ATDD means. I would say that the driving part may not have been part of XP from the beginning.

I'm also not sure what difference it makes ...

Ron Jeffries
www.XProgramming.com
I have two cats, and a big house full of cat stuff. The cats fight and divide up the house, messing up their own
lives. Nice work cats. Meow.

[Non-text portions of this message have been removed]

headers

Adam Sroka | 13 May 2012 01:52

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

On Sat, May 12, 2012 at 4:40 PM, RonJeffries <ronjeffries <at> acm.org> wrote:
>
> There are people who think to use product-level tests to "drive" something
> -- I'm not sure just what -- in a way that is analogous to the way that
> microscopic programmer tests can be used to drive design. I would suppose
> that's what ATDD means. I would say that the driving part may not have been
> part of XP from the beginning.
>

The intent is that the customer expresses his desires in terms of
concrete examples and those are automated so that immediately when
they pass we can say the feature is done. It's actually a very nice
idea, and it sorta works. I say sorta works, because in my experience
it works real well for a while and then becomes a pain to maintain.

Also, the notion that customers will write, let alone maintain,
automated tests is questionable. Which inevitably means that it is we
lowly programmers who end up maintaining yet another framework and yet
another bunch of slow, often brittle, integration tests. That is,
until the point where they become too noisy or too cumbersome and we
just start turning off or ignoring them.

Also, there is no refactoring step that I am aware of. So, it's
another form of test-first programming, but there's no steering wheel
for driving 

> I'm also not sure what difference it makes …
>

None, really. People are going to continue to have good ideas, and

(Continue reading)

headers

RonJeffries | 13 May 2012 02:16

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


On May 12, 2012, at 7:52 PM, Adam Sroka wrote:

> On Sat, May 12, 2012 at 4:40 PM, RonJeffries <ronjeffries <at> acm.org> wrote:
>> 
>> There are people who think to use product-level tests to "drive" something
>> -- I'm not sure just what -- in a way that is analogous to the way that
>> microscopic programmer tests can be used to drive design. I would suppose
>> that's what ATDD means. I would say that the driving part may not have been
>> part of XP from the beginning.
>> 
> 
> The intent is that the customer expresses his desires in terms of
> concrete examples and those are automated so that immediately when
> they pass we can say the feature is done. It's actually a very nice
> idea, and it sorta works.

Yes, we did that from the beginning. I think I originated the notion of treating the tests as defining the
story and treating any changes after that as a new story. The idea was to treat any miscommunication or
learning as just that, not a yes i did no you didn't kind of thing.

> I say sorta works, because in my experience
> it works real well for a while and then becomes a pain to maintain.

Do you mean to maintain making up examples, or to maintain the old ones as still running.
> 
> Also, the notion that customers will write, let alone maintain,
> automated tests is questionable. Which inevitably means that it is we
> lowly programmers who end up maintaining yet another framework and yet
> another bunch of slow, often brittle, integration tests. That is,

(Continue reading)

headers

Charlie Poole | 13 May 2012 08:14

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

Hi Ron,

>> Also, there is no refactoring step that I am aware of. So, it's
>> another form of test-first programming, but there's no steering wheel
>> for driving 
>
> Yes. That's me, too. I'm not sure where the Driving D comes from. Maybe it is about discovering the
requirements by building stuff? I just don't know.

I don't find that "Driving" means the same thing with acceptance tests
as it does with developer tests. Either that or the second D means
"Discovery."

That's the crux of the difference for me. From the programming point
of view Design is an act of creation. Stories OTOH are just out there
to be discovered and understood. I'm like to use acceptance tests as
the artifact around which the Customer and developer work in order to
tease out the details of stories.

I hasten to add that this isn't 100% true. Sometimes there is an act
of creation involved in coming up with a new story. For example, who
knew that people would want to communicate over Facebook before
Facebook existed. But mostly, the requirements exist on the business
side and we want to find - not create - them.

When using tools like FIT to create new tests, the Customer and
programmer are forced to interact to define and create the fixture. If
this need to collaborate was not already there, we would probably want
to invent some other reason to do it. That's why I tend to push back
against the notion of turning the creation of tests completely over to

(Continue reading)

headers

Steven Gordon | 13 May 2012 08:48

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

On Sat, May 12, 2012 at 4:52 PM, Adam Sroka <adam.sroka <at> gmail.com> wrote:
> On Sat, May 12, 2012 at 4:40 PM, RonJeffries <ronjeffries <at> acm.org> wrote:
>>
>> There are people who think to use product-level tests to "drive" something
>> -- I'm not sure just what -- in a way that is analogous to the way that
>> microscopic programmer tests can be used to drive design. I would suppose
>> that's what ATDD means. I would say that the driving part may not have been
>> part of XP from the beginning.
>>
>
> The intent is that the customer expresses his desires in terms of
> concrete examples and those are automated so that immediately when
> they pass we can say the feature is done.

This is really not quite right, unless by 'feature', you mean 'story
slice' and by 'done', you mean not yet 'done done'.

You see, the tests should represent just a single slice of a feature,
very rarely a whole feature.  And when the acceptance tests pass, then
there needs to be some interactions rather than an end to activities
for the story.  The interactions should include:

* exploratory testing to find defects (after all, the initial
acceptance tests are mostly happy paths - the defects discovered can
lead to writing some negative acceptance tests), and

* customer evaluation to make sure that the software really does what
they want (in case the test was too simplistic or now seeing the
software in action makes the customer realize they asked for not quite
the right thing).  Customer evaluation also facilitates the discovery

(Continue reading)

headers

Joshua Kerievsky | 14 May 2012 07:14

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

On Sat, May 12, 2012 at 4:40 PM, RonJeffries <ronjeffries <at> acm.org> wrote:

> There are people who think to use product-level tests to "drive" something
> -- I'm not sure just what -- in a way that is analogous to the way that
> microscopic programmer tests can be used to drive design. I would suppose
> that's what ATDD means. I would say that the driving part may not have been
> part of XP from the beginning.
>

Product-level tests may be used to drive design.

I'm also not sure what difference it makes ...
>

Driving the design from microtests is often called Inside-Out.  Driving the
design from customer/acceptance/storytests is often called Outside In.  In
both cases, you start with a failing test, and evolve a design, refactoring
all along the way.  Refactoring happens at either level, as depicted in the
diagram here: http://www.industrialxp.org/storyTdd.html

best,
jk

[Non-text portions of this message have been removed]

headers

Steven Gordon | 11 May 2012 19:11

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

TDD is not the same as "unit tests" - it is driving development by
doing unit testing first.

ATDD is not the same as "customer tests" - it is driving development
by doing customer tests first (even before TDD).

The only time I would ever argue that customer tests may be more
useful that unit tests is the case of mitigating legacy code that is
particularly difficult to retroactively unit test.  In that case,
neither can be done before the code, because the code has already been
written.

Once the customer tests are in, we have basis for triaging the legacy
code, which can result in the decision that much of the unchanging
legacy code does not warrant retrofitting unit tests now that the
customer tests provide sufficient regression testing.

SteveG

On Fri, May 11, 2012 at 9:37 AM, Charlie Poole <charliepoole <at> gmail.com> wrote:
> Hi,
>
> It's interesting that ATDD as you have defined it (and I think you have it
> right)
> is pretty much exactly the XP practice called "Customer Tests" or earlier
> "Acceptance Tests."
>
> And TDD is the XP practice "Test-Driven Development."
>
> I'll deal with BDD later.

(Continue reading)

headers

Adam Sroka | 11 May 2012 19:17

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

On Fri, May 11, 2012 at 10:11 AM, Steven Gordon <sgordonphd <at> gmail.com> wrote:
>
> The only time I would ever argue that customer tests may be more
> useful that unit tests is the case of mitigating legacy code that is
> particularly difficult to retroactively unit test. In that case,
> neither can be done before the code, because the code has already been
> written.
>
> Once the customer tests are in, we have basis for triaging the legacy
> code, which can result in the decision that much of the unchanging
> legacy code does not warrant retrofitting unit tests now that the
> customer tests provide sufficient regression testing.
>

Yep, but to really get coverage you have to refactor the code that you
surrounded with customer tests to be microtestable. Otherwise there
are too many permutations to deal with and/or you get a bunch of slow
tests.

Once you have done that you can test drive new features into the same
part of that codebase.

headers

Charlie Poole | 11 May 2012 19:29

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

Hi Steven,

> TDD is not the same as "unit tests" - it is driving development by
> doing unit testing first.

Yes... more precisely, by doing it one test at a time.

The only thing I said about unit tests is that "there exists a
(relatively small) group of people who claim you don't need unit
tests." This is a true statement. I happen to believe those people are
wrong.

> ATDD is not the same as "customer tests" - it is driving development
> by doing customer tests first (even before TDD).

AFAIK, that's what the "Customer Tests" practice has always meant. In
early days, we often said you should specify the tests first. Later,
it became more common to automate them first as well.

> The only time I would ever argue that customer tests may be more
> useful that unit tests is the case of mitigating legacy code that is
> particularly difficult to retroactively unit test. In that case,
> neither can be done before the code, because the code has already been
> written.
>
> Once the customer tests are in, we have basis for triaging the legacy
> code, which can result in the decision that much of the unchanging
> legacy code does not warrant retrofitting unit tests now that the
> customer tests provide sufficient regression testing.

(Continue reading)

headers

M. Manca | 11 May 2012 19:46

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

Il 11/05/2012 19:11, Steven Gordon ha scritto:
>  
>
> TDD is not the same as "unit tests" - it is driving development by
> doing unit testing first.
>
Why? I didn't remember that TDD specifies that I have to start your
application development at unit level. Generally the 2 things are the
same but please remember that in C language and in the full set of
procedural not properly object oriented languages there is always a
main() like function that should be the application skeleton. You should
consider its file a unit but it is quite reductive.
>
>
> ATDD is not the same as "customer tests" - it is driving development
> by doing customer tests first (even before TDD).
>
> The only time I would ever argue that customer tests may be more
> useful that unit tests is the case of mitigating legacy code that is
> particularly difficult to retroactively unit test. In that case,
> neither can be done before the code, because the code has already been
> written.
>
I would like you may give me a short example of a strategy to design a
complex process software application developed starting by unit tests
first. Just to help me to understand better what you say.
>
>
> Once the customer tests are in, we have basis for triaging the legacy
> code, which can result in the decision that much of the unchanging

(Continue reading)

headers

Charlie Poole | 11 May 2012 19:54

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

Hi,

On Fri, May 11, 2012 at 10:46 AM, M. Manca <m.manca <at> micronengineering.it> wrote:
>
>
>
> Il 11/05/2012 19:11, Steven Gordon ha scritto:
>
>
> >
> >
> > TDD is not the same as "unit tests" - it is driving development by
> > doing unit testing first.
> >
> Why? I didn't remember that TDD specifies that I have to start your
> application development at unit level. Generally the 2 things are the
> same but please remember that in C language and in the full set of
> procedural not properly object oriented languages there is always a
> main() like function that should be the application skeleton. You should
> consider its file a unit but it is quite reductive.
>
TDD doesn't tell you how to start overall development at all. It tells
you how to start implementing a story.

Charlie

headers

M. Manca | 11 May 2012 21:04

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

Il 11/05/2012 19:54, Charlie Poole ha scritto:
>  
>
> Hi,
>
> On Fri, May 11, 2012 at 10:46 AM, M. Manca
> <m.manca <at> micronengineering.it <mailto:m.manca%40micronengineering.it>>
> wrote:
> >
> >
> >
> > Il 11/05/2012 19:11, Steven Gordon ha scritto:
> >
> >
> > >
> > >
> > > TDD is not the same as "unit tests" - it is driving development by
> > > doing unit testing first.
> > >
> > Why? I didn't remember that TDD specifies that I have to start your
> > application development at unit level. Generally the 2 things are the
> > same but please remember that in C language and in the full set of
> > procedural not properly object oriented languages there is always a
> > main() like function that should be the application skeleton. You should
> > consider its file a unit but it is quite reductive.
> >
> TDD doesn't tell you how to start overall development at all. It tells
> you how to start implementing a story.
>
Yes but he said "doing unit testing first" so in this case it is not a

(Continue reading)

headers

Steven Gordon | 11 May 2012 21:24

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

On Fri, May 11, 2012 at 12:04 PM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>
>
> Il 11/05/2012 19:54, Charlie Poole ha scritto:
>
> >
> >
> > Hi,
> >
> > On Fri, May 11, 2012 at 10:46 AM, M. Manca
> > <m.manca <at> micronengineering.it <mailto:m.manca%40micronengineering.it>>
>
> > wrote:
> > >
> > >
> > >
> > > Il 11/05/2012 19:11, Steven Gordon ha scritto:
> > >
> > >
> > > >
> > > >
> > > > TDD is not the same as "unit tests" - it is driving development by
> > > > doing unit testing first.
> > > >
> > > Why? I didn't remember that TDD specifies that I have to start your
> > > application development at unit level. Generally the 2 things are the
> > > same but please remember that in C language and in the full set of
> > > procedural not properly object oriented languages there is always a

(Continue reading)

headers

M. Manca | 11 May 2012 22:36

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

Il 11/05/2012 21:24, Steven Gordon ha scritto:
>  
>
> On Fri, May 11, 2012 at 12:04 PM, M. Manca
> <m.manca <at> micronengineering.it
> <mailto:m.manca%40micronengineering.it>>wrote:
>
> > **
> >
> >
> > Il 11/05/2012 19:54, Charlie Poole ha scritto:
> >
> > >
> > >
> > > Hi,
> > >
> > > On Fri, May 11, 2012 at 10:46 AM, M. Manca
> > > <m.manca <at> micronengineering.it
> <mailto:m.manca%40micronengineering.it>
> <mailto:m.manca%40micronengineering.it>>
> >
> > > wrote:
> > > >
> > > >
> > > >
> > > > Il 11/05/2012 19:11, Steven Gordon ha scritto:
> > > >
> > > >
> > > > >
> > > > >

(Continue reading)

headers

Charlie Poole | 11 May 2012 23:22

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

Hi,"

> I tried to say that if is correct to
> say that unit tests may be considered part of TDD it isn't correct to
> restrict TDD to only unit tests as I understand by what means "doing
> unit testing first".

Some people use TDD to refer to both customer/acceptance tests
and developer/unit tests. Other people keep using TDD to mean
only unit tests. For good communication, I think it's important to
know what definition is being used.

I don't think it's correct to say that one definition is correct. 

Charlie

headers

M. Manca | 11 May 2012 23:38

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

Il 11/05/2012 23:22, Charlie Poole ha scritto:
>  
>
> Hi,"
>
> > I tried to say that if is correct to
> > say that unit tests may be considered part of TDD it isn't correct to
> > restrict TDD to only unit tests as I understand by what means "doing
> > unit testing first".
>
> Some people use TDD to refer to both customer/acceptance tests
> and developer/unit tests. Other people keep using TDD to mean
> only unit tests. For good communication, I think it's important to
> know what definition is being used.
>
> I don't think it's correct to say that one definition is correct. 
>
True but a lot of confusion born in this way.
Suppose that I speak with you in my language (Italian) or worst using my
mother tongue Friulian (to be correct in Italy there are 5 minority
languages: Friulian, Sardinian, Slovenian, German,  and French and a lot
of more or less known dialects) and you with your, I think we should
have some problems to communicate right? So we should agree to use a
language that both understand and speak. But if we give to the same word
2 different meanings and every time I need to explain you what one word
means for me and you need to do the same to me I think we aren't in a
much better situation then the initial one.

This is exactly what I think about the jungle of equivalent terminology
there is about TDD, BDD, ATDD and so on. Sure different people arrived

(Continue reading)

headers

Charlie Poole | 11 May 2012 23:53

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

Hi Massimo,

On Fri, May 11, 2012 at 2:38 PM, M. Manca <m.manca <at> micronengineering.it> wrote:
>
>
>
> Il 11/05/2012 23:22, Charlie Poole ha scritto:
>
>
> >
> >
> > Hi,"
> >
> > > I tried to say that if is correct to
> > > say that unit tests may be considered part of TDD it isn't correct to
> > > restrict TDD to only unit tests as I understand by what means "doing
> > > unit testing first".
> >
> > Some people use TDD to refer to both customer/acceptance tests
> > and developer/unit tests. Other people keep using TDD to mean
> > only unit tests. For good communication, I think it's important to
> > know what definition is being used.
> >
> > I don't think it's correct to say that one definition is correct. 
> >
> True but a lot of confusion born in this way.
> Suppose that I speak with you in my language (Italian) or worst using my
> mother tongue Friulian (to be correct in Italy there are 5 minority
> languages: Friulian, Sardinian, Slovenian, German, and French and a lot
> of more or less known dialects) and you with your, I think we should

(Continue reading)

headers

MarvinToll.com | 12 May 2012 04:09

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

hmmm...

This is fascinating (to me)... at some risk of aggrandizing my nemesis.

When teaching I often randomly exchange the terms "Test Driven Development" and "Test Driven Design" to
make the abstracted point Dr. Gordon expressed below.

However, I've never experienced the freedom implied by the notion that unit tests will ALWAYS be an
insufficient proof.

Maybe I've missed a point obvious to everyone else?... but if I belatedly accept the premise it changes my
whole notion of 'just enough'.

In other words, unit testing becomes an exercise in 'just enough' to validate the design... not an endless
exercise in creating mountains of 'just enough' test code to validate the implementation.

And this would mean that I no longer need to start code reviews with the unit tests to ensure they are
sufficient as an implementation "proof"... although I may want to as a design inquiry.

And it means I've needlessly spent the last ten years of my life with a slight feeling of guilt because I've
been intuitively satisfied that driving out the the design was sufficient... but never had an empirical
way to express the useful limits of the exercise.

Said another way, I've never had an empirical principle to communicate to others my boundaries on the
cost/benefit of unit testing.

Said a third way, I've struggled to explain why I favor in-container testing over outside-the-container testing.

Said a fourth way, it is no longer about code coverage... it is about design (or pattern) coverage.

(Continue reading)

headers

M. Manca | 12 May 2012 08:21

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

Il 12/05/2012 04:09, MarvinToll.com ha scritto:
>  
>
> hmmm...
>
> This is fascinating (to me)... at some risk of aggrandizing my
> nemesis. 
>
> When teaching I often randomly exchange the terms "Test Driven
> Development" and "Test Driven Design" to make the abstracted point Dr.
> Gordon expressed below.
>
> However, I've never experienced the freedom implied by the notion that
> unit tests will ALWAYS be an insufficient proof.
>
> Maybe I've missed a point obvious to everyone else?... but if I
> belatedly accept the premise it changes my whole notion of 'just enough'.
>
> In other words, unit testing becomes an exercise in 'just enough' to
> validate the design... not an endless exercise in creating mountains
> of 'just enough' test code to validate the implementation.
>
Mmmm.... you are entering in a jungle...
>
>
> And this would mean that I no longer need to start code reviews with
> the unit tests to ensure they are sufficient as an implementation
> "proof"... although I may want to as a design inquiry.
>
> And it means I've needlessly spent the last ten years of my life with

(Continue reading)

headers

MarvinToll.com | 14 May 2012 13:31

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

Let me wade a little further into the jungle.

If we presume that in a typical application (Pareto Principle) perhaps 80% of our code is using existing
formalized patterns gleaned from the last 50+ years of application development... do we need to 'unit
test' that our patterns 'work'?

Said another way, when our TDD design calls for a particular pattern... what do we need to 'unit test'?

In the interest of a concrete example... let's use a Caching Singleton pattern:  http://wp.me/P1FU3L-n4 

Doesn't the selection of this pattern call for a unit test confirming that it was implemented
correctly---not, that the pattern 'works'?

If so, we need an assertCachingSingleton method that verifies two things:

1. That the class is an enum
2. That any Map fields are ConcurrentHashMaps

Now... that still leaves 20% of our application where we are more concerned with ensuring the
implementation 'works' then the design choice was implemented properly.

Thoughts?

_Marvin

--- In extremeprogramming <at> yahoogroups.com, "M. Manca" <m.manca <at> ...> wrote:
>
> Il 12/05/2012 04:09, MarvinToll.com ha scritto:
> >  
> >

(Continue reading)

headers

Buddha Buck | 14 May 2012 14:30

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

On Mon, May 14, 2012 at 7:31 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com> wrote:

> Said another way, when our TDD design calls for a particular pattern... what do we need to 'unit test'?

The more I think about this question, the less it makes sense to me.

In TDD, the tests+refactoring are driving the design.  I would think
that in a TDD'd solution, by the time the design "calls" for a
particular patter, there are already plenty of tests in place.

headers

MarvinToll.com | 14 May 2012 14:39

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

Ah... yes... and the implication is that IF an applicable formalized "pattern" is discovered - and
implemented... those unit tests that led to the discovery can be disgarded as no longer useful.

... and the assert becomes:

assertCachingSingleton(Object myCachingSingleton)

--- In extremeprogramming <at> yahoogroups.com, Buddha Buck <blaisepascal <at> ...> wrote:
>
> On Mon, May 14, 2012 at 7:31 AM, MarvinToll.com <MarvinToll <at> ...> wrote:
> 
> > Said another way, when our TDD design calls for a particular pattern... what do we need to 'unit test'?
> 
> The more I think about this question, the less it makes sense to me.
> 
> In TDD, the tests+refactoring are driving the design.  I would think
> that in a TDD'd solution, by the time the design "calls" for a
> particular pattern, there are already plenty of tests in place.
>

headers

Charlie Poole | 14 May 2012 18:43

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

Hi Marvin,

I write tests for code I create. I only know how to test code, not patterns.

Following the link, it appears that CachingSingleton is your
implementation. If I wanted to use it, I would expect that you had tests
for it. In fact, I probably wouldn't use it unless you published the tests.
That said, if I used it, I wouldn't have to test it. I'd have to test how
my code was using it.

Charlie

On Mon, May 14, 2012 at 4:31 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> Let me wade a little further into the jungle.
>
> If we presume that in a typical application (Pareto Principle) perhaps 80%
> of our code is using existing formalized patterns gleaned from the last 50+
> years of application development... do we need to 'unit test' that our
> patterns 'work'?
>
> Said another way, when our TDD design calls for a particular pattern...
> what do we need to 'unit test'?
>
> In the interest of a concrete example... let's use a Caching Singleton
> pattern: http://wp.me/P1FU3L-n4
>

(Continue reading)

headers

M. Manca | 14 May 2012 18:57

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

Il 14/05/2012 18:43, Charlie Poole ha scritto:
> Hi Marvin,
>
> I write tests for code I create. I only know how to test code, not patterns.
>
> Following the link, it appears that CachingSingleton is your
> implementation. If I wanted to use it, I would expect that you had tests
> for it. In fact, I probably wouldn't use it unless you published the tests.
> That said, if I used it, I wouldn't have to test it. I'd have to test how
> my code was using it.
Yes, as for legacy code or also to test libraries classes/functions that
were written by others.
>
> Charlie
>
> On Mon, May 14, 2012 at 4:31 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:
>
>> **
>>
>>
>> Let me wade a little further into the jungle.
>>
>> If we presume that in a typical application (Pareto Principle) perhaps 80%
>> of our code is using existing formalized patterns gleaned from the last 50+
>> years of application development... do we need to 'unit test' that our
>> patterns 'work'?
>>
>> Said another way, when our TDD design calls for a particular pattern...
>> what do we need to 'unit test'?
>>

(Continue reading)

headers

MarvinToll.com | 14 May 2012 21:21

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

The notion of testing patterns starts with defining a pattern.  In the case of the Caching Singleton
referenced, Joshua Bloch has defined the pattern.  ( http://wp.me/P1FU3L-n4 )

If you trust the pattern, as I do in this case, then what I need to test is that the pattern was implemented
correctly.  Dr. Gordon has already made the point that we can't normally "prove" an implementation anyway
- so why should I bother?

The API for testing patterns can be similar to assertPatternName... such as:

public static void assertCachingSingleton(Object cachingSingleton){

// Verify enum
// Verify all Map fields are ConcurrentHashMaps

}

Said another way, we normally don't test that dependent frameworks 'work'... we trust they have already
been tested.  Testing patterns is similar... there is no need to verify a mature pattern 'works'... what we
need to verfiy is that the pattern was implemented correctly.

My first experiment with this notion of testing patterns was the open source project TestUtil
( http://gtcgroup.com/testutil.html ) in 2005.  Because the Java Bean pattern is so well-defined it made
an excellent proof-of-concept.

_Marvin

--- In extremeprogramming <at> yahoogroups.com, Charlie Poole <charliepoole <at> ...> wrote:
>
> Hi Marvin,
>

(Continue reading)

headers

Steven Gordon | 14 May 2012 21:38

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

Marvin, you have the cart before the horse again.

What matters is whether the code reliably meets the requirements, not how
well it complies with some pattern.  The pattern only exists to help people
come up with a good design, not to ensure that the code that uses that
pattern works correctly.  The test helps ensure that it works correctly.

Furthermore, many of us believe that starting with a pattern is a form
premature commitment that often results in more complex code than necessary
to meet the requirements.  We believe that we should write the simplest
code that meets the requirement using TDD, but when complexity (usually
emerging after meeting several requirements) creates the need for a more
sophisticated solution, then we see the need to refactor towards a known
design pattern.  We only need the tests we developed with the code to
ensure that the new refactored design meets the same requirements (not that
it complies with the pattern).

SteveG

On Mon, May 14, 2012 at 12:21 PM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> The notion of testing patterns starts with defining a pattern. In the case
> of the Caching Singleton referenced, Joshua Bloch has defined the pattern.
> ( http://wp.me/P1FU3L-n4 )
>
> If you trust the pattern, as I do in this case, then what I need to test
> is that the pattern was implemented correctly. Dr. Gordon has already made

(Continue reading)

headers

Charlie Poole | 14 May 2012 21:50

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

Hi Steve,

On Mon, May 14, 2012 at 12:38 PM, Steven Gordon <sgordonphd <at> gmail.com> wrote:
> Marvin, you have the cart before the horse again.
>
> What matters is whether the code reliably meets the requirements, not how
> well it complies with some pattern.  The pattern only exists to help people
> come up with a good design, not to ensure that the code that uses that
> pattern works correctly.  The test helps ensure that it works correctly.
>
> Furthermore, many of us believe that starting with a pattern is a form
> premature commitment that often results in more complex code than necessary
> to meet the requirements.  We believe that we should write the simplest
> code that meets the requirement using TDD, but when complexity (usually
> emerging after meeting several requirements) creates the need for a more
> sophisticated solution, then we see the need to refactor towards a known
> design pattern.  We only need the tests we developed with the code to
> ensure that the new refactored design meets the same requirements (not that
> it complies with the pattern).

It's subtle. I think it's OK to start with a pattern _in_your_head_. It would be
a form of premature commitment to simply go ahead and implement it out
of whole cloth based on that preconception.

A lot of the time, when doing TDD, we retain a number of (potentially
conflicting)
notions in our brains, holding back from picking one of them until a test forces
us to do so. I think that tension provides a lot of the energy for doing TDD.

I've started with an idea I might use a pattern lots of times. Sometimes the

(Continue reading)

headers

MarvinToll.com | 15 May 2012 14:09

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

Steve,

You don't "start with a pattern"... you use TDD to discover the pattern that is applicable in a particular
context... or you make up your own new pattern if you are doing something not already  formalized over the
past 50 years of application development.

The same way an artist (painter) has a palette of colors to work with... the artist picks the color for a
situation, or, forms new colors (by combining) if none of the colors in the palette are able to express the
desired intent.

My experience is that the "Agile" movement has a knee-jerk reaction of 'fear, uncertainty and doubt' every
time one talks about leveraging the technical learnings of the past five decades.  Asserting that people
are incapable of selecting from past human experience without "result(ing) in more complex code than
necessary to meet the requirements".

My experience is the opposite.  I find poor code (technical debt) emanating from those that are pattern
deficient in their practise... and better code from those that are pattern sensitive.

_Marvin
http://PatternEnabled.com 

--- In extremeprogramming <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...> wrote:
>
> Marvin, you have the cart before the horse again.
> 
> What matters is whether the code reliably meets the requirements, not how
> well it complies with some pattern.  The pattern only exists to help people
> come up with a good design, not to ensure that the code that uses that
> pattern works correctly.  The test helps ensure that it works correctly.
>

(Continue reading)

headers

Charlie Poole | 14 May 2012 21:44

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

Hi Marvin,

On Mon, May 14, 2012 at 12:21 PM, MarvinToll.com
<MarvinToll <at> gtcgroup.com> wrote:
>
>
>
> The notion of testing patterns starts with defining a pattern. In the case of the Caching Singleton
referenced, Joshua Bloch has defined the pattern. ( http://wp.me/P1FU3L-n4 )

Actually, I believe it really starts with observing a pattern present
in some code. At some point, one may abstract a definition.

>
> If you trust the pattern, as I do in this case, then what I need to test is that the pattern was implemented
correctly. Dr. Gordon has already made the point that we can't normally "prove" an implementation anyway
- so why should I bother?
>
> The API for testing patterns can be similar to assertPatternName... such as:
>
> public static void assertCachingSingleton(Object cachingSingleton){
>
> // Verify enum
> // Verify all Map fields are ConcurrentHashMaps
>
> }
>
> Said another way, we normally don't test that dependent frameworks 'work'... we trust they have already
been tested. Testing patterns is similar... there is no need to verify a mature pattern 'works'... what we
need to verfiy is that the pattern was implemented correctly.

(Continue reading)

headers

Nayan Hajratwala | 14 May 2012 22:01

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

On May 14, 2012, at 3:22 PM, "MarvinToll.com" <MarvinToll <at> gtcgroup.com>
wrote:

Said another way, we normally don't test that dependent frameworks
'work'... we trust they have already been tested. Testing patterns is
similar... there is no need to verify a mature pattern 'works'... what we
need to verfiy is that the pattern was implemented correctly.

When I introduce a framework into a project, I do indeed write tests around
the features from the framework that I'm going to use. These tests capture
the behavior that I need and allow me to swap out/upgrade the framework in
the without fear that my usage of it will break.

I never trust that they have already been adequately tested.

When I teach people about this, i sometimes refer to these as learning
tests.

[Non-text portions of this message have been removed]

headers

JeffGrigg | 15 May 2012 06:42

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

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> The notion of testing patterns starts with defining a pattern.
> In the case of the Caching Singleton referenced, Joshua Bloch
> has defined the pattern.  ( http://wp.me/P1FU3L-n4 )
>
> If you trust the pattern, as I do in this case, then what I
> need to test is that the pattern was implemented correctly.
> ...
>
> The API for testing patterns can be similar to
> assertPatternName... such as:
> 
> public static void assertCachingSingleton(Object cachingSingleton) {
>    // Verify enum
>    // Verify all Map fields are ConcurrentHashMaps
> }
>
> Said another way, ... there is no need to verify a mature
> pattern 'works'... what we need to verfiy is that the pattern
> was implemented correctly.

> My first experiment with this notion of testing patterns was
> the open source project TestUtil
> ( http://gtcgroup.com/testutil.html ) in 2005.  Because the
> Java Bean pattern is so well-defined it made an excellent
> proof-of-concept.

I'm not saying that what you're doing is "wrong."  Far from it; I have done similar things at times.

But I think you may be defining a technique from edge and boundary cases, rather than mainstream cases.

(Continue reading)

headers

MarvinToll.com | 15 May 2012 14:46

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

In-line below.

--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> wrote:
>
> I prefer to write tests of behavior, rather than tests of form.

MDT> I agree when there is no formalized pattern, behavior tests are required... even if we can't achieve
perfection (per Dr. Gordon).

When there is a formalized pattern how do you know the pattern was implemented correctly?

> Like Charlie Poole, when I TDD the Observer pattern, I write tests to verify that the correct results are
achived, rather than testing that the expected implementation artifacts are present.  That is, for the
Observer pattern, I test that when data changing event "X" happens, the updated data is sent to field "Y" on
the screen.  That the model does not depend on the view can be asserted by observation, or possibly by tests. 
But the details of implementation do not need to be tested directly.  We know that the implementaiton is
good or sufficient by the fact that it produces the expected observable results.  (And that it does not have
offensive "smells," such as inappropriate dependencies, as determined by inspection/code review.)
>

MDT> This gets into an advanced concept... which I've not yet tried to express.  Suffice it to say, you will
not find the Observer pattern on the Pattern Enabled Development list.  And I agree, if you use this pattern
you will need to test as you have described.  A pattern with similar characteristics that is on the list is a
"Controller".  These types of patterns require traditional 'behavioral' unit testing.

> 
> I have found thread synchronization code to be particularly challenging to test.  Generally, I find that I
need multiple threads running in the test -- which is not "natural" to the xUnit frameworks which
generally run single-threaded.  And I need to control timing of the test threads with signals and

(Continue reading)

headers

Steven Gordon | 15 May 2012 15:14

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

On Tue, May 15, 2012 at 5:46 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
>
> In-line below.
>
>
> --- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...>
> wrote:
> >
> > I prefer to write tests of behavior, rather than tests of form.
>
> MDT> I agree when there is no formalized pattern, behavior tests are
> required... even if we can't achieve perfection (per Dr. Gordon).
>

SG: I was contrasting with the word "prove".  TDD tests are about design,
assurance and support for refactoring -  not proof (or perfection).

>
> When there is a formalized pattern how do you know the pattern was
> implemented correctly?
>
>
>
If the code works for the problem at hand and yet was an incorrectly
implemented pattern, then the pattern could not have been the appropriate
way to solve the problem.  For me, that kind of overkill is a bigger issue

(Continue reading)

headers

MarvinToll.com | 15 May 2012 15:44

TDD as a "proof"... or not?

In-line
--- In extremeprogramming <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...> wrote:
>
> On Tue, May 15, 2012 at 5:46 AM, MarvinToll.com <MarvinToll <at> ...>wrote:
> >
> 
> SG: I was contrasting with the word "prove".  TDD tests are about design,
> assurance and support for refactoring -  not proof (or perfection).

MDT: Steve, I'm not sure if I hear this in the way intended.

What I'm hearing: TDD (or, Test Driven Design) is about discovering design etc. and not proving code
'works'.  One can not normally use TDD as a technical "proof" any way... so there is no point in trying to
misuse it for that purpose.   

> If the code works for the problem at hand and yet was an incorrectly
> implemented pattern, then the pattern could not have been the appropriate
> way to solve the problem. 

MDT: Agreed!  And the way one discovers that selection of a pattern is the wrong 'fit'?

> Review is the only way to discover either problem.  The discovery could
> well happen when the code is reused/extended to implement some future story
> instead of at creation time.  This is one of the benefits of a shared code
> base.
>

MDT: This is an area I'm continuing to explore.  Is there a way to use TDD to reduce the amount of manual 'review'?

(Continue reading)

headers

M. Manca | 15 May 2012 16:22

Re: TDD as a "proof"... or not?

Il 15/05/2012 15:44, MarvinToll.com ha scritto:
Marvin,
I think that when some engineers have different ideas and they compare
honestly what they think every part may learn something, may say
something wrong and may say somthing right. Exchanging ideas and writing
here may be effective more or less as a brainstorming.
>  
>
> In-line
> --- In extremeprogramming <at> yahoogroups.com
> <mailto:extremeprogramming%40yahoogroups.com>, Steven Gordon
> <sgordonphd <at> ...> wrote:
> >
> > On Tue, May 15, 2012 at 5:46 AM, MarvinToll.com <MarvinToll <at> ...>wrote:
> > >
> >
> > SG: I was contrasting with the word "prove". TDD tests are about design,
> > assurance and support for refactoring - not proof (or perfection).
>
> MDT: Steve, I'm not sure if I hear this in the way intended.
>
> What I'm hearing: TDD (or, Test Driven Design) is about discovering
> design etc. and not proving code 'works'. One can not normally use TDD
> as a technical "proof" any way... so there is no point in trying to
> misuse it for that purpose.
>
> > If the code works for the problem at hand and yet was an incorrectly
> > implemented pattern, then the pattern could not have been the
> appropriate
> > way to solve the problem.

(Continue reading)

headers

Steven Gordon | 15 May 2012 17:15

Re: TDD as a "proof"... or not?

On Tue, May 15, 2012 at 6:44 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> In-line
> --- In extremeprogramming <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...>
> wrote:
> >
> > On Tue, May 15, 2012 at 5:46 AM, MarvinToll.com <MarvinToll <at> ...>wrote:
> > >
> >
> > SG: I was contrasting with the word "prove". TDD tests are about design,
> > assurance and support for refactoring - not proof (or perfection).
>
> MDT: Steve, I'm not sure if I hear this in the way intended.
>
> What I'm hearing: TDD (or, Test Driven Design) is about discovering design
> etc. and not proving code 'works'. One can not normally use TDD as a
> technical "proof" any way... so there is no point in trying to misuse it
> for that purpose.
>
> > If the code works for the problem at hand and yet was an incorrectly
> > implemented pattern, then the pattern could not have been the appropriate
> > way to solve the problem.
>
> MDT: Agreed! And the way one discovers that selection of a pattern is the
> wrong 'fit'?
>
> > Review is the only way to discover either problem. The discovery could

(Continue reading)

headers

MarvinToll.com | 15 May 2012 21:38

Re: TDD as a "proof"... or not?

Steve... 

A couple of question for you:

Do you think my work with Patterns in the context of Global Sourcing at Ford Motor Company was done to
explicitly increase or reduce effective collaboration?

Asked another way, do you think one can just rip-out one of the fundamental tenants of XP - co-location - and
NOT find a suitable ('just enough') substitute practise to encourage
cross-cultural/cross-time-zone/cross-native-language communication... even if it takes six years
to do so?

Do you think that I think Patterns are a foolproof communication strategy... or a starting point to a
coherent conversation at 5:00 AM EST?

Do you think that training/mentoring/coaching folks to understand and use patterns effectively
necessarily "reduces agility and learning" which damages the opportunity "for the team to improve its skills"?

_Marvin

--- In extremeprogramming <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...> wrote:
>
> On Tue, May 15, 2012 at 6:44 AM, MarvinToll.com <MarvinToll <at> ...>wrote:
> 
> > MDT: This is an area I'm continuing to explore. Is there a way to use TDD
> > to reduce the amount of manual 'review'?
> >
> >
> I mean open sharing of code and ideas, not some third party sitting down
> and reading through the code.

(Continue reading)

headers

MarvinToll.com | 15 May 2012 23:09

Re: TDD as a "proof"... or not?

Alright... I'll answer these question and then I'll shut-up about this.

--- In extremeprogramming <at> yahoogroups.com, "MarvinToll.com" <MarvinToll <at> ...> wrote:
>
> Do you think working with Patterns in the context of Global Sourcing at Ford Motor Company was done to
explicitly increase or reduce effective collaboration?
> 

The effort invested in establishing, communicating and providing a reference application for patterns
(as a starting point) was an explicit investment to encourage voluntary collaboration across four
continents.  Ford Motor Company does NOT mandate or measure or verify if anyone uses the patterns offered.

> Asked another way, do you think one can just rip-out one of the fundamental tenants of XP - co-location - and
NOT find a suitable ('just enough') substitute practise to encourage
cross-cultural/cross-time-zone/cross-native-language communication... even if it takes six years
to do so?
>

The drammatic negative impact of distributed development cries-out for a compensating solution...
however imperfect. 

> Do you think that that Patterns are meant as a foolproof communication strategy... or a starting point to a
coherent conversation at 5:00 AM EST?
>

I have found enormous personal satisfaction in being able to collaborate globally with a development
community grounded in a consistent architectural and design starting point.

> Do you think that training/mentoring/coaching folks to understand and use patterns effectively
necessarily "reduces agility and learning" which damages the opportunity "for the team to improve its skills"?

(Continue reading)

headers

JeffGrigg | 16 May 2012 11:18

Re: TDD as a "proof"... or not?

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> ... or a starting point to a coherent conversation at 5:00 AM EST?

I've always had a hard time holding up my end of a coherent conversation at 5am EST.  ;->

[And, quite ironically, I've just checked the clocks:  It just happens to be right after 5am EST right now!]

headers

James Grenning | 15 May 2012 18:48

Re: TDD as a "proof"... or not?

On May 15, 2012, at 8:44 AM, MarvinToll.com wrote:
> 
> MDT: This is an area I'm continuing to explore. Is there a way to use TDD to reduce the amount of manual 'review'?
> 
> 
I've seen where the focus of the reviews shift after adopting TDD and pair programming.  Us decided we could
focus in reviews on the key questions:
	Does the code do what it is supposed to do (a.k.a. are the tests right)?
	Is the interface to the production code clean and easy to use.

These two objectives could be achieved by just reviewing the design context and the test cases.  We felt
these were the biggest architectural impact and needed to be reviewed beyond just the people doing the work.

We left the internal quality such as names and function length up to the people that pair programmed the
changes.  This let us get the most from our valuable review time.  It focused  the review on checking for
completeness and interface.

thanks, James

--------------------------------------------------------------------------------------------
James Grenning					Author of TDD for Embedded C
www.renaissancesoftware.net			http://pragprog.com/titles/jgade/
www.renaissancesoftware.net/blog
www.twitter.com/jwgrenning

[Non-text portions of this message have been removed]

headers

RonJeffries | 14 May 2012 23:49

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

Marvin,

On May 14, 2012, at 7:31 AM, MarvinToll.com wrote:

> Said another way, when our TDD design calls for a particular pattern... what do we need to 'unit test'?

Well, to begin with, TDD is not a kind of "unit testing". Given that we are implementing some capability,
what we write tests for, in a loop, is the next bit of functionality we are trying to build. If it happens to
have singleton behavior, then we may well write tests that test singleton kinds of things, not because we
are implementing a singleton pattern but because we want that kind of behavior.

If someone were to write tests toward a pattern, I would be somewhat concerned that they were not getting the
best results from TDD.

Ron Jeffries
www.XProgramming.com
If another does not intend offense, it is wrong for me to seek it;
if another does indeed intend offense, it is foolish for me to permit it.
  -- Kelly Easterley

[Non-text portions of this message have been removed]

headers

MarvinToll.com | 15 May 2012 14:19

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

Gee whiz Ron... In my copy of "Test-Driven Development: By Example" Chapter 29 is entitled "xUnit
Patterns".  If the word "Unit" is not short for "Unit Testing" what does "Unit" mean?

Do we need Martin Fowler to sort this out before we can have a meaningful discussion about tactics for
testing formalized patterns?

_Marvin

--- In extremeprogramming <at> yahoogroups.com, RonJeffries <ronjeffries <at> ...> wrote:
>
> Marvin,
> 
> On May 14, 2012, at 7:31 AM, MarvinToll.com wrote:
> 
> > Said another way, when our TDD design calls for a particular pattern... what do we need to 'unit test'?
> 
> 
> Well, to begin with, TDD is not a kind of "unit testing". 
>
> Ron Jeffries
> www.XProgramming.com

headers

Buddha Buck | 15 May 2012 14:37

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

On Tue, May 15, 2012 at 8:19 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com> wrote:
> Gee whiz Ron... In my copy of "Test-Driven Development: By Example" Chapter 29 is entitled "xUnit
Patterns".  If the word "Unit" is not short for "Unit Testing" what does "Unit" mean?

xUnit is a name (or a naming pattern).  At one point, it may have had
something to do with what the authors at the time considered to be
unit testing, but the use changes.

It's common for names to outlast their original meaning.  When was the
last time AT&T did anything with telegraphy?  What does "Exxon" mean?

>
> Do we need Martin Fowler to sort this out before we can have a meaningful discussion about tactics for
testing formalized patterns?

What of a pattern do you want to test?  For that matter, how do you
test a pattern?  Why do you want to test a pattern?

Keep in mind that when Christopher Alexander introduced the idea of
design patterns, he titled his book "A Pattern Language", and used
patterns as a means of communication, a means of people to talk to
each other about how they solved recurring problems.

I'm much rather test that the code I am writing solves my problem than
that it follows a particular pattern.  I may need to be able to access
an expensive-to-compute value throughout the lifetime of my
application without incurring the cost of computing it more than once,
so that's the behavior I'm going to test, not that I'm using a
CachedSingleton pattern.

(Continue reading)

headers

RonaldEJeffries | 15 May 2012 14:38

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

--- In extremeprogramming <at> yahoogroups.com, "MarvinToll.com" <MarvinToll <at> ...> wrote:
>
> Gee whiz Ron... In my copy of "Test-Driven Development: By Example" Chapter 29 is entitled "xUnit
Patterns".  If the word "Unit" is not short for "Unit Testing" what does "Unit" mean?

It refers to Unit testing. xUnit bills itself as a unit testing framework. 

TDD, however, is not a unit testing practice. It is not a testing practice at all. It is a design practice that
uses tests to set small next goals, and programming to meet those goals, and refactoring to improve the design.

It also appears that you have a question about testing code implementing patterns, or perhaps about how one
might TDD toward a pattern. The latter has been answered by two or three people, yet your responses do not
seem to ecpress understanding or satisfaction.

Perhaps you could restate your question in the light of what has been said so far? 

And since this thread is about incremental value of BDD over TDD, perhaps you'd be kind enough to start a new
thread about your question?

Regards,

Ron

headers

MarvinToll.com | 15 May 2012 15:30

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

You're right... I lost interest in my own thread (sorry).

It doesn't sound like we have many consistent facts to work with at this time...  although I appreciate
Charlie's anecdotal experience and subsequent elaboration:

> The two biggest contributions of BDD to (at least my) TDD have been
> * The notion of organizing tests by a context
> * The importance of syntax in testing tools

From my perspective, I withdraw the question.

_Marvin

--- In extremeprogramming <at> yahoogroups.com, "RonaldEJeffries" <ronjeffries <at> ...> wrote:
> 
> And since this thread is about incremental value of BDD over TDD, perhaps you'd be kind enough to start a new
thread about your question?
> 
> Regards,
> Ron

headers

extremeprogrammer | 16 May 2012 09:26

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

--- In extremeprogramming <at> yahoogroups.com, "MarvinToll.com" <MarvinToll <at> ...> wrote:
>
> Gee whiz Ron... In my copy of "Test-Driven Development: By Example" Chapter 29 is entitled "xUnit
Patterns".  If the word "Unit" is not short for "Unit Testing" what does "Unit" mean?

"xUnit Patterns" means "Patterns for Using xUnit", not "Using xUnit to Test Patterns"

headers

JeffGrigg | 12 May 2012 09:13

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

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> However, I've never experienced the freedom implied by the
> notion that unit tests will ALWAYS be an insufficient proof.
> 
> Maybe I've missed a point obvious to everyone else?... but
> if I belatedly accept the premise it changes my whole notion
> of 'just enough'.

Automated regression tests are never sufficient to *PROVE* that the implementation is correct.

The best that they can do is (possibly with some minimal code review) give you high confidence that the
implementation performs as expected in all the circumstances reasonable people can think of.

To see this, consider this problem:

How many tests are sufficient to test a Java 'int' increment function?

Two?  Three?  Six?

OK.  Write them.

Now (after writing the tests), here's a reasonable implementation:

   public static int increment(int input) {
      return input + 1;
   }

Did great, didn't we?

But hey; I'm an Evil Programmer.  I'll put in this implementation:

(Continue reading)

headers

M. Manca | 12 May 2012 09:57

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

Il 12/05/2012 09:13, JeffGrigg ha scritto:
>  
>
> --- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> > However, I've never experienced the freedom implied by the
> > notion that unit tests will ALWAYS be an insufficient proof.
> >
> > Maybe I've missed a point obvious to everyone else?... but
> > if I belatedly accept the premise it changes my whole notion
> > of 'just enough'.
>
> Automated regression tests are never sufficient to *PROVE* that the
> implementation is correct.
>
> The best that they can do is (possibly with some minimal code review)
> give you high confidence that the implementation performs as expected
> in all the circumstances reasonable people can think of.
>
> To see this, consider this problem:
>
> How many tests are sufficient to test a Java 'int' increment function?
>
> Two? Three? Six?
>
> OK. Write them.
>
> Now (after writing the tests), here's a reasonable implementation:
>
> public static int increment(int input) {
> return input + 1;

(Continue reading)

headers

JeffGrigg | 12 May 2012 10:58

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

Here's some test code:

   public void testSecondCharacter() {
      assertEquals('b', secondChar("abc"));
      assertEquals('y', secondChar("xyz"));
      assertEquals('o', secondChar("wonderful"));
   }

and an implementation:

   public static char secondChar(String inputString) {
      return inputString.charAt(1);
   }

Are the tests sufficient?

Well, maybe.  It depends on what assumptions you make.  Specifically, what do you want to happen for null and
input strings of less than two characters?  (Like "X" and "".)

I would argue that in some cases the tests and implementation above *ARE* sufficient.  Maybe we have good
reason to believe that null values and short strings will never happen.  We might be reading from a
non-nullable column in a database.  And there could be a corporate policy or government regulation or
industry standard stating that all codes used here have at least three characters.

I'd say that testing and coding for conditions that "can't happen" may violate YAGNI (You Aren't Going to
Need It).

On a more philosophical note...

What part of the TDD practice forces you to consider those three cases?

(Continue reading)

headers

M. Manca | 12 May 2012 11:21

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

Il 12/05/2012 10:58, JeffGrigg ha scritto:
>  
>
> Here's some test code:
>
> public void testSecondCharacter() {
> assertEquals('b', secondChar("abc"));
> assertEquals('y', secondChar("xyz"));
> assertEquals('o', secondChar("wonderful"));
> }
>
> and an implementation:
>
> public static char secondChar(String inputString) {
> return inputString.charAt(1);
> }
>
> Are the tests sufficient?
>
No, at least you need to test for empty string and a string made by only
1 char.
>
>
> Well, maybe. It depends on what assumptions you make. Specifically,
> what do you want to happen for null and input strings of less than two
> characters? (Like "X" and "".)
>
> I would argue that in some cases the tests and implementation above
> *ARE* sufficient. Maybe we have good reason to believe that null
> values and short strings will never happen. We might be reading from a

(Continue reading)

headers

Charlie Poole | 11 May 2012 22:07

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

I think you mistook Steve's meaning. I'm pretty sure he meant "doing unit
tests
before writing the code" rather than "before anything."

Charlie

On Fri, May 11, 2012 at 12:04 PM, M. Manca <m.manca <at> micronengineering.it>wrote:

> **
>
>
> Il 11/05/2012 19:54, Charlie Poole ha scritto:
>
> >
> >
> > Hi,
> >
> > On Fri, May 11, 2012 at 10:46 AM, M. Manca
> > <m.manca <at> micronengineering.it <mailto:m.manca%40micronengineering.it>>
>
> > wrote:
> > >
> > >
> > >
> > > Il 11/05/2012 19:11, Steven Gordon ha scritto:
> > >
> > >
> > > >
> > > >
> > > > TDD is not the same as "unit tests" - it is driving development by

(Continue reading)

headers

M. Manca | 11 May 2012 22:39

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

Il 11/05/2012 22:07, Charlie Poole ha scritto:
> I think you mistook Steve's meaning. I'm pretty sure he meant "doing unit
> tests
> before writing the code" rather than "before anything."
my note was about the second part of the sentence, he wrote :

TDD is not the same as "unit tests" - it is driving development by
doing unit testing first.

I think is wrong use "doing unit testing first" because unit meaning is related to a unit of source code so I
think the correct sentence should be:

TDD is not the same as "unit tests" - it is driving development by
doing tests first.

>
> Charlie
>
> On Fri, May 11, 2012 at 12:04 PM, M. Manca <m.manca <at> micronengineering.it>wrote:
>
>> **
>>
>>
>> Il 11/05/2012 19:54, Charlie Poole ha scritto:
>>
>>>
>>> Hi,
>>>
>>> On Fri, May 11, 2012 at 10:46 AM, M. Manca
>>> <m.manca <at> micronengineering.it <mailto:m.manca%40micronengineering.it>>

(Continue reading)

headers

M. Manca | 11 May 2012 19:33

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

Il 11/05/2012 18:37, Charlie Poole ha scritto:
> Hi,
>
> It's interesting that ATDD as you have defined it (and I think you have it
> right)
> is pretty much exactly the XP practice called "Customer Tests" or earlier
> "Acceptance Tests."
>
> And TDD is the XP practice "Test-Driven Development."
>
> I'll deal with BDD later.
>
> In XP, it has always been quite clear that we don't choose between doing
> TDD
> and ATDD... they are just two of the practices that you have to do, if you
> want
> to do XP. I think this is quite important - in or out of XP - because there
> exists
> a (relatively small) group of people who claim you don't need unit tests. I
> think
> you do in all but the most trivial applications.
>
> Whether you choose to use the same tool for developer and customer tests
> or a different tool is a matter for the individual project. I do think it's
> important
> for a developer to know whether an indivual test is a customer test or a
> developer test. The distinction is quiet clear: a developer can always
> change
> the success criterion for a developer test, without consulting anyone else;
> only

(Continue reading)

headers

Charlie Poole | 11 May 2012 19:52

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

Hi,

> Thanks Charlie, I agree almost completely with you about the "real
> things" and leaving the multiple names to their own world, now I think
> we have understood each other.
>
> As I said there is too much nomenclature and different definitions for
> the same or quite the same practices, I don't like this.

Me either. It's a pet annoyance of mine that everyone doing agile seems
to want to create their own terminology, which competes with existing
terms and seems to me to cause more confusion than clarification.

> The only thing I can add is that in my personal opinion BDD has a syntax
> more oriented to customers/stakeholders and is a good thing to establish
> a business oriented language between 2 very different type of
> professionals. I think that in the history of software development were
> about 50-60 years of a never ending story about misunderstandings
> between stakeholders and developers so if Dan North syntax helps, should
> be better use it.

Suppose a team is writing customer tests using an entirely different tool,
one that uses tables to express the tests, for example, or one that uses
commands in a text file. I don't think anybody would call that BDD, but
it could still be customer test driven development of some kind.

It seems illogical to me to make the tools define the methodology.

> What should I had preferred? A syntax "extension" to be used in XP to
> introduce the Dan North syntax for user stories/scenarios only to put a

(Continue reading)

headers

M. Manca | 11 May 2012 20:54

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

Il 11/05/2012 19:52, Charlie Poole ha scritto:
> Hi,
>
>> Thanks Charlie, I agree almost completely with you about the "real
>> things" and leaving the multiple names to their own world, now I think
>> we have understood each other.
>>
>> As I said there is too much nomenclature and different definitions for
>> the same or quite the same practices, I don't like this.
> Me either. It's a pet annoyance of mine that everyone doing agile seems
> to want to create their own terminology, which competes with existing
> terms and seems to me to cause more confusion than clarification.
>
>> The only thing I can add is that in my personal opinion BDD has a syntax
>> more oriented to customers/stakeholders and is a good thing to establish
>> a business oriented language between 2 very different type of
>> professionals. I think that in the history of software development were
>> about 50-60 years of a never ending story about misunderstandings
>> between stakeholders and developers so if Dan North syntax helps, should
>> be better use it.
> Suppose a team is writing customer tests using an entirely different tool,
> one that uses tables to express the tests, for example, or one that uses
> commands in a text file. I don't think anybody would call that BDD, but
> it could still be customer test driven development of some kind.
>
> It seems illogical to me to make the tools define the methodology.
Let me correct myself: first of all BDDers use feature instead of user
story (just the last "syntax error" I made but the meaning is always the
same), then I mean "As a-I want-so that" (also "In order to-As a- I
need" is a good template)and Given-When-Then (plus all the ins and outs)

(Continue reading)

headers

extremeprogrammer | 11 May 2012 14:08

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

I think if we wait another year or so, then BDD would have had a couple of extra practices added to it that will
make it identical to what XP was in 1999.

--- In extremeprogramming <at> yahoogroups.com, "Kay A Pentecost" <tranzpupy <at> ...> wrote:
>
> Hi, Everybody,
> 
> I'd really like somebody to write those paragraphs, and one on what they
> mean by ATDD.  I've done a lot of TDD -- I write everything I can (and some
> things I probably can't) test-driven, but BDD seems more higher level to
> me... and I'd like to understand it more.
> 
> Kay Pentecost
> 
> > -----Original Message-----
> > From: extremeprogramming <at> yahoogroups.com
> > [mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of RonJeffries
> > Sent: Tuesday, May 08, 2012 7:50 AM
> > To: extremeprogramming <at> yahoogroups.com
> > Subject: Re: [XP] Re: Facts for incremental value of BDD? (Beyond TDD)
> > 
> <snip>
> > 
> > 
> > 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.
> > 
> > Ron Jeffries
>

(Continue reading)

headers

extremeprogrammer | 9 May 2012 15:12

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

--- In extremeprogramming <at> yahoogroups.com, "PAUL" <beckfordp <at> ...> wrote:
> 
>  I think the problem is how we teach this stuff. 

One problem is that a large number of developers want to proclaim expertise in something when (a) they know
what the acronym stands for and (b) they've read an opening paragraph of a blog, declared the rest TL;DR,
and then assumed they understand what it is about.

Another is that many developers don't actually want to know this stuff but do it because their team / manager
/ organisation requires it.

Regards,

Lance

headers

MarvinToll.com | 9 May 2012 18:23

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

Lance,

This was precisely the reason for the post... an attempt to dig beyond the "opening paragraph" (which is
usually filled with inflated expectations) and extract some depth (however fragmented at the moment)
from those that would recommend BDD (based on experience, not reading) as having value beyond that
provided by TDD.

It appeared to me that the XP community might have (previously) endorsed BDD so I thought this a good place to
turn for a fact-based analysis.

I now understand BDD fragmentation makes an analysis difficult... although it is not clear to me yet that it
is impossible.

_Marvin

--- In extremeprogramming <at> yahoogroups.com, "extremeprogrammer" <LanceWalton <at> ...> wrote:
>
> One problem is that a large number of developers want to proclaim expertise in something when (a) they know
what the acronym stands for and (b) they've read an opening paragraph of a blog, declared the rest TL;DR,
and then assumed they understand what it is about.
>

headers

Steve Ropa | 9 May 2012 16:23

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

Sadly, there is another group that doesn't want to do it because "it is new and you haven't convinced me that
any of this new stuff works anyway."  They flip the bozo bit quickly, say "this will never work" and move on to
the same tired old ways they have always done things....poorly.

extremeprogrammer <LanceWalton <at> mac.com> wrote:

>--- In extremeprogramming <at> yahoogroups.com, "PAUL" <beckfordp <at> ...> wrote:
>> 
>>  I think the problem is how we teach this stuff. 
>
>One problem is that a large number of developers want to proclaim expertise in something when (a) they know
what the acronym stands for and (b) they've read an opening paragraph of a blog, declared the rest TL;DR,
and then assumed they understand what it is about.
>
>Another is that many developers don't actually want to know this stuff but do it because their team /
manager / organisation requires it.
>
>Regards,
>
>Lance
>

[Non-text portions of this message have been removed]

headers

MarvinToll.com | 10 May 2012 02:33

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

Steve,

There is also a group that was quick to embrace CASE in the 80's and regretted it.

Then there is the group that proclaimed (synchronous) client/server was the solution.

Then came CORBA... and then (hold your nose) Entity Beans.

Then came CASE again... only this time it was called MDD.

Then JAX RPC... which lasted for about 18 months...

Then came Cloud computing... which was all about inflated expectations until the first bill arrived.

And now we have Functional Programing... that begins a pitch with an anti-imperative blast as if OO
languages never existed.

My point?

Please don't risk broad brushing those that want legitimate analysis (empirical or anecdotal) with those
that are late adopters.  My observation is that our industry has been quick to set aside fact-based
decision making in favor of inflated expectations.

_Marvin

--- In extremeprogramming <at> yahoogroups.com, Steve Ropa <theropas <at> ...> wrote:
>
> Sadly, there is another group that doesn't want to do it because "it is new and you haven't convinced me that
any of this new stuff works anyway."  They flip the bozo bit quickly, say "this will never work" and move on to
the same tired old ways they have always done things....poorly.

(Continue reading)

headers

JeffGrigg | 10 May 2012 05:14

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

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> There is also a group that was quick to embrace CASE in the
> 80's and regretted it.

I was in the group who embraced CASE in the 80's and was quite successful with it.  "Wildly successful" is how
I'd describe it.

Now much of that functionality is in IDEs and UML tools, and we just expect it.

> Then there is the group that proclaimed (synchronous)
> client/server was the solution.

And that actually worked quite well too.  Managing the software on distributed client machines proved to be
a problem -- until we developed, deployed and widely adopted Internet-style automated updates that we
largely take for granted today.  Now we call it "rich client."  And I've been successful with that, too.

> Then came CORBA... and then (hold your nose) Entity Beans.

Let's not forget Microsoft's DCOM.  I have to admit that it was painful to watch people repeat the same
mistakes with each new technology.  People need to learn and to remember that network round-trips are not
free:  They take time.  And they are not reliable.  We've yet to really address those issues in a really
satisfactory way.

> Then came CASE again... only this time it was called MDD.
> 
> Then JAX RPC... which lasted for about 18 months...

At least people recognized the CORBA/DCOM/RMI patterns early on.

> Then came Cloud computing... which was all about inflated

(Continue reading)

headers

M. Manca | 10 May 2012 08:19

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

Il 10/05/2012 05:14, JeffGrigg ha scritto:
>  
>
> --- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> > There is also a group that was quick to embrace CASE in the
> > 80's and regretted it.
>
> I was in the group who embraced CASE in the 80's and was quite
> successful with it. "Wildly successful" is how I'd describe it.
>
> Now much of that functionality is in IDEs and UML tools, and we just
> expect it.
>
> > Then there is the group that proclaimed (synchronous)
> > client/server was the solution.
>
> And that actually worked quite well too. Managing the software on
> distributed client machines proved to be a problem -- until we
> developed, deployed and widely adopted Internet-style automated
> updates that we largely take for granted today. Now we call it "rich
> client." And I've been successful with that, too.
>
> > Then came CORBA... and then (hold your nose) Entity Beans.
>
> Let's not forget Microsoft's DCOM. I have to admit that it was painful
> to watch people repeat the same mistakes with each new technology.
> People need to learn and to remember that network round-trips are not
> free: They take time. And they are not reliable. We've yet to really
> address those issues in a really satisfactory way.
>

(Continue reading)

headers

MarvinToll.com | 10 May 2012 13:56

Multi-Core Processing

Jeff... fyi - one solution for multi-core processing without having to move to a functional programming
language... http://wp.me/P1FU3L-rR 

--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> wrote:
>
> --- "MarvinToll.com" <MarvinToll <at> > wrote:
> > There is also a group that was quick to embrace CASE in the
> > 80's and regretted it.
> 
> I was in the group who embraced CASE in the 80's and was quite successful with it.  "Wildly successful" is how
I'd describe it.
> 
> Now much of that functionality is in IDEs and UML tools, and we just expect it.
> 
> 
> > Then there is the group that proclaimed (synchronous)
> > client/server was the solution.
> 
> And that actually worked quite well too.  Managing the software on distributed client machines proved to
be a problem -- until we developed, deployed and widely adopted Internet-style automated updates that we
largely take for granted today.  Now we call it "rich client."  And I've been successful with that, too.
> 
> 
> > Then came CORBA... and then (hold your nose) Entity Beans.
> 
> Let's not forget Microsoft's DCOM.  I have to admit that it was painful to watch people repeat the same
mistakes with each new technology.  People need to learn and to remember that network round-trips are not
free:  They take time.  And they are not reliable.  We've yet to really address those issues in a really
satisfactory way.
>

(Continue reading)

headers

JeffGrigg | 10 May 2012 22:18

Re: Multi-Core Processing

I'm looking for a multi-core solution with performance that scales (near) linearly to the hundreds (and
thousands) of cores/CPUs that we should expect to be routinely using a few years from now.  We need
something that works well on typical business problems and is usable by typical business programmers,
hopefully without massive retraining or turnover.

I want something with the performance of Map-Reduce, that is usable on typical business problems, maybe
with relational databases [as it seems that we as an industry are incapable of challenging that
assumption], and reasonably usable for typical business programmers.  I haven't seen it yet.

The SOAj thing doesn't even double performance.  But on the positive side, for the short term it looks like
good stuff.  Off hand, I think I might describe it as "making good use of the resources, technologies and
tools that are currently easily available."  In other words, it's the result of a good and effective
optimization exercise.  It's a good and effective thing to do, for the short term.

But I'm looking for a much more significant game changer.  I can see that we need it.  But I have not seen the
answer.  ...yet.

--- "MarvinToll.com" <MarvinToll <at> ...> wrote:
> Jeff... fyi - one solution for multi-core processing without
> having to move to a functional programming language...
> http://wp.me/P1FU3L-rR

http://patternenabled.com/soaj-framework/soaj-performancescalability/

>> --- "MarvinToll.com" <MarvinToll <at> > wrote:
>>> And now we have Functional Programing... that begins a pitch
>>> with an anti-imperative blast as if OO languages never existed.

> --- "JeffGrigg" <jeffreytoddgrigg <at> > wrote:
>> We need a solution to the multi-core CPU issues that are

(Continue reading)

headers

John Roth | 10 May 2012 23:20

Re: Re: Multi-Core Processing

A couple of years ago Tim Bray did a shoestring project to see how well 
he could make a typical system administration task scale to multiple 
cores. The results were not encouraging.

http://www.tbray.org/ongoing/When/200x/2008/05/01/Wide-Finder-2

John Roth

On 5/10/12 2:18 PM, JeffGrigg wrote:
>
> I'm looking for a multi-core solution with performance that scales 
> (near) linearly to the hundreds (and thousands) of cores/CPUs that we 
> should expect to be routinely using a few years from now. We need 
> something that works well on typical business problems and is usable 
> by typical business programmers, hopefully without massive retraining 
> or turnover.
>
> I want something with the performance of Map-Reduce, that is usable on 
> typical business problems, maybe with relational databases [as it 
> seems that we as an industry are incapable of challenging that 
> assumption], and reasonably usable for typical business programmers. I 
> haven't seen it yet.
>
> The SOAj thing doesn't even double performance. But on the positive 
> side, for the short term it looks like good stuff. Off hand, I think I 
> might describe it as "making good use of the resources, technologies 
> and tools that are currently easily available." In other words, it's 
> the result of a good and effective optimization exercise. It's a good 
> and effective thing to do, for the short term.
>

(Continue reading)

headers

JeffGrigg | 10 May 2012 23:49

Re: Multi-Core Processing

So he has a huge number of large log files to scan for file names that he wants to count.  And it didn't occur to
him to try Map-Reduce?  This seems (to me) like a natural for Map-Reduce.

http://en.wikipedia.org/wiki/MapReduce

http://en.wikipedia.org/wiki/Hadoop

--- John Roth <JohnRoth1 <at> ...> wrote:
> A couple of years ago Tim Bray did a shoestring project to see
> how well he could make a typical system administration task
> scale to multiple cores. The results were not encouraging.
> 
> http://www.tbray.org/ongoing/When/200x/2008/05/01/Wide-Finder-2
> 
> John Roth

headers

John Roth | 11 May 2012 00:54

Re: Re: Multi-Core Processing

I thought he explained his intentions fairly well, and they excluded 
special purpose software.

John Roth

On 5/10/12 3:49 PM, JeffGrigg wrote:
>
> So he has a huge number of large log files to scan for file names that 
> he wants to count. And it didn't occur to him to try Map-Reduce? This 
> seems (to me) like a natural for Map-Reduce.
>
> http://en.wikipedia.org/wiki/MapReduce
>
> http://en.wikipedia.org/wiki/Hadoop
>
> --- John Roth <JohnRoth1 <at> ...> wrote:
> > A couple of years ago Tim Bray did a shoestring project to see
> > how well he could make a typical system administration task
> > scale to multiple cores. The results were not encouraging.
> >
> > http://www.tbray.org/ongoing/When/200x/2008/05/01/Wide-Finder-2
> >
> > John Roth
>
> 

[Non-text portions of this message have been removed]

headers

MarvinToll.com | 11 May 2012 13:03

Re: Multi-Core Processing

Jeff... it doesn't double performance compared to the COBOL platform... we got about 6x overall
performance gains compared to Java without multi-core processing. 

--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg <at> ...> wrote:
>
> The SOAj thing doesn't even double performance.  But on the positive side, for the short term it looks like
good stuff.  Off hand, I think I might describe it as "making good use of the resources, technologies and
tools that are currently easily available."  In other words, it's the result of a good and effective
optimization exercise.  It's a good and effective thing to do, for the short term.

headers

Steve Ropa | 10 May 2012 08:10

RE: Re: Facts for incremental value of BDD? (Beyond TDD)

Nah, I was just lamenting how many times I've seen people look at a good
idea, decide that until someone has "proven it" somehow, they wouldn't even
try it.  I imagine there are still some people who don't think TDD is a good
idea, I just don't enjoy cleaning up after them.  I don't see how we can use
something called fact based decision making if we aren't even willing to
try.

I see the list of items that folks tried and then seen a way to improve on
them as a success story.

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of MarvinToll.com
Sent: Wednesday, May 09, 2012 6:34 PM
To: extremeprogramming <at> yahoogroups.com
Subject: [XP] Re: Facts for incremental value of BDD? (Beyond TDD)

Steve,

There is also a group that was quick to embrace CASE in the 80's and
regretted it.

Then there is the group that proclaimed (synchronous) client/server was the
solution.

Then came CORBA... and then (hold your nose) Entity Beans.

Then came CASE again... only this time it was called MDD.

Then JAX RPC... which lasted for about 18 months...

(Continue reading)

headers

MarvinToll.com | 10 May 2012 14:05

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

hmmm... In my mind these (eventually) unsuccessful ventures have a similar theme... heavier-weight...
in contrast to approaches that (eventually) demonstrate durability... lighter-weight.

So for me, part of the analysis (by those that have actually used BDD) is whether it is light-weight or simply
cluttering the TDD landscape for little gain?

--- In extremeprogramming <at> yahoogroups.com, "Steve Ropa" <theropas <at> ...> wrote:
>
> I see the list of items that folks tried and then seen a way to improve on
> them as a success story.
>

headers

Steven Gordon | 10 May 2012 15:04

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

Marvin,

For once, I think I mostly agree with you.

Most 20th century technologies were too heavy (and many current
technologies that have a 20th century legacy inherit that bloatedness).
 Some manage to be successful despite it (just like some low quality
software have also been successful).

I believe the consensus here is that some BDD ideas can add value to TDD
and ATDD without increasing heaviness in many circumstances and in the
right hands.  But, this consensus is based on experience-based
understanding, not FACTs.

I also believe the consensus here is that it (like all the agile practices
and techniques) is best learned by working collaboratively on real projects
with people who already understand how to apply it.  Although the
literature can bootstrap that learning, the literature is not enough.  Even
a set of patterns that have worked well on some projects is not as
productive a way to learn as working collaboratively on real work with
people who already have the knowledge.

SteveG

On Thu, May 10, 2012 at 5:05 AM, MarvinToll.com <MarvinToll <at> gtcgroup.com>wrote:

> **
>
>
> hmmm... In my mind these (eventually) unsuccessful ventures have a similar

(Continue reading)

headers

MarvinToll.com | 11 May 2012 13:19

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



--- In extremeprogramming <at> yahoogroups.com, Steven Gordon <sgordonphd <at> ...> wrote:
>
> Marvin,
> 
> For once, I think I mostly agree with you.

headers

Steve | 6 May 2012 14:43

Re: How to do this?

Since it sounds like a complete rewrite in c# I recommend checking out growing object oriented software
guided by tests. Written by Steve freeman and nat pryce. The talk about beginning a system with a walking
skeleton. This is a minimum end to end slice of the system. In you case one service method all the way down to
the class that interacts with the database. Check it out www.mockobjects.com

Thanks
Steven Solomon 

On May 6, 2012, at 5:24 AM, "Theresa Forster" <theresajayne <at> minuet-uk.com> wrote:

> I have a conundrum, I have a VB.NET WCF service I need to recode and clean
> up into C#,
> 
> I want to drive it out using Agile using just the name of the service and
> the existing database at the top and bottom allowing XP and Agile to drive
> out the logic in the middle. 
> 
> The old system is using CSLA which is mind bogglingly slow. So I need to use
> something maybe NHibernate or something. I don't know as I haven't driven it
> out yet.
> 
> My question is where should I start? What should I do as a test first? The
> WCF declaration is fixed for the moment, but we will be adding restful to
> the mix going forward. So should I build an adapter pattern behind the WCF
> or maybe a Controller Pattern. 
> 
> Being new to agile I am not sure which pattern fits here nor where to go
> forward, so some suggestions would be really helpful.
> 
> Thanks

(Continue reading)

headers

Charlie Poole | 6 May 2012 17:48

Re: How to do this?

Hi Theresa,

You can go from the top to the bottom: force a class into existence that
handles the API.
That class may end up as an adapter but _you_don't_know_that_yet_ ! You'll
discover it
as you add the implementation.

You can go from the bottom to the top: create CRUD methods that access the
database
and proceed from there. By using these methods.

You can slice vertically rather than horizontally: Create one API method at
a time, driving
all the way through to the database, first with no real functionality, then
with minimal
functionality, then with exceptions.

You can do some mix of the above approaches. 

I would personally lean toward the top-down approach with refinement
occuring in
vertical slices, but don't let that influence you. The biggest factor in
the decision is your
own experience and level of comfort with each approach. So long as you end
up linking
all the pieces and driving out all the functionality, you'll be successful.

In addition, you should explicitly look at the existing tests - assuming
there are any - and

(Continue reading)

headers

PAUL | 7 May 2012 08:18

Re: How to do this?


Hi Thereasa,

I think Ron picked up on the most important point you make here:

> Beiing new to Agile......

TDD is a difficult skill to master, so cutting your teeth on a knarly refactor may not be the best place to start.

If you are confident then small refactors supported by tests (first) is the ideal way to go. This is a skill in
itself and as someone mentioned, MIcheal  Feathers book is a good place to start exploring...

The difficulies II have found with the refactoring route are:

1. The requirements arent known, so you don't know what tests are needed.
2. Even when you do know, the code is so knarly that it is hard to get tests around it, and you find yourself
refactoring without a safety net, resulting in accidental breakages.

One approach that has worked well for me is to go through the code with someone who knows it, reverse
engineering the requirements and capturing them in tests.

Once I know what the code is meant to do, I've always cheated and rewritten swaths of it :) Most of the time,
small refactors would of got me there, but the pain :) When I'm not confident i know what the code is doing I
tend to stick to the refactors. It's a judgement.

Another benefit of working with the original authors is that they get to learn "better ways" of doing
things. So the knowledge sharing goes both ways. You get to learn about the domain and they get to learn
about  clean code.

Paul.

(Continue reading)

headers

PAUL | 7 May 2012 08:26

Re: How to do this?

Hi Theresa,

One thing I forgot to mention, is that once you know what the code is doing. It makes sense to capture that in
user stories. If you've got all the stories with complete acceptance criteria then rewrite versus
refactor is a moot point (IMHO).

Paul.

--- In extremeprogramming <at> yahoogroups.com, "PAUL" <beckfordp <at> ...> wrote:
>
> 
> Hi Thereasa,
> 
> I think Ron picked up on the most important point you make here:
> 
> > Beiing new to Agile......
> 
> TDD is a difficult skill to master, so cutting your teeth on a knarly refactor may not be the best place to start.
> 
> If you are confident then small refactors supported by tests (first) is the ideal way to go. This is a skill
in itself and as someone mentioned, MIcheal  Feathers book is a good place to start exploring...
> 
> The difficulies II have found with the refactoring route are:
> 
> 1. The requirements arent known, so you don't know what tests are needed.
> 2. Even when you do know, the code is so knarly that it is hard to get tests around it, and you find yourself
refactoring without a safety net, resulting in accidental breakages.
> 
> One approach that has worked well for me is to go through the code with someone who knows it, reverse
engineering the requirements and capturing them in tests.

(Continue reading)

headers

Steven Gordon | 7 May 2012 09:25

Re: Re: How to do this?

One approach I have use to address both issues Paul points out (knowing the
actual requirements and the need to unknot some code before you have any
code that can support a unit test) is to instead start by automating
acceptance tests.

By first automating acceptance tests, you will learn what the actual
requirements are.  You will also build a safety net that is likely to tell
you whether or not the refactorings you do before good unit tests can be
put in place broke the software.

SteveG

On Sun, May 6, 2012 at 11:18 PM, PAUL <beckfordp <at> btopenworld.com> wrote:

> **
>
>
>
> Hi Thereasa,
>
> I think Ron picked up on the most important point you make here:
>
> > Beiing new to Agile......
>
> TDD is a difficult skill to master, so cutting your teeth on a knarly
> refactor may not be the best place to start.
>
> If you are confident then small refactors supported by tests (first) is
> the ideal way to go. This is a skill in itself and as someone mentioned,
> MIcheal Feathers book is a good place to start exploring...

(Continue reading)

headers

Theresa Forster | 7 May 2012 12:35

RE: Re: How to do this?

Thanks for all your input, however the original authors are long gone, and
the only person who knows anything about the code I am looking at is me, The
other dev is unable to assist but he knows how the system works not how the
code does, although swathes of the code is either dead or part of another
package, they created dlls which just contain all the business logic for ALL
the 5 different apps in the one dll, and each solution contains ALL parts of
the dll in source not binary. 

I started with the first function - GetToken()  this takes a datacontract as
input GetTokenRequest (yes I know I should drop the "Get" but because 5
other programs use this I can't)  and returns a GetTokenResponse,  So I
drove out the request and response classes based on the existing
(username+password in one Token and TokenState in the other (Token being a
guid) TokenState being an enum) Now the next task is to drive out the logic,
so I will drive out the Adapter and have the GetToken() WCF code behind call
the Adapter.GetToken() which will do the login process (that's all it does) 

That is step one, next function step2 - etc.

Is this the right way to do it?

Theresa

-----Original Message-----
From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of Steven Gordon
Sent: 07 May 2012 08:25
To: extremeprogramming <at> yahoogroups.com
Subject: Re: [XP] Re: How to do this?

(Continue reading)

headers

Steve Ropa | 7 May 2012 18:03

RE: Re: How to do this?


Well, the first question in my mind is "Do you have a test for that?"  In
other words, did you write a test showing that the old functionality is
correct, then write the new C# object in such a way as to make the test
continue to pass?  I have found that the act of writing those tests goes an
incredibly long way toward understanding what the old code does.  

Steve

From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of Theresa Forster
Sent: Monday, May 07, 2012 4:35 AM
To: extremeprogramming <at> yahoogroups.com
Subject: RE: [XP] Re: How to do this?

Thanks for all your input, however the original authors are long gone, and
the only person who knows anything about the code I am looking at is me, The
other dev is unable to assist but he knows how the system works not how the
code does, although swathes of the code is either dead or part of another
package, they created dlls which just contain all the business logic for ALL
the 5 different apps in the one dll, and each solution contains ALL parts of
the dll in source not binary. 

I started with the first function - GetToken() this takes a datacontract as
input GetTokenRequest (yes I know I should drop the "Get" but because 5
other programs use this I can't) and returns a GetTokenResponse, So I
drove out the request and response classes based on the existing
(username+password in one Token and TokenState in the other (Token being a
guid) TokenState being an enum) Now the next task is to drive out the logic,
so I will drive out the Adapter and have the GetToken() WCF code behind call

(Continue reading)

headers

Nayan Hajratwala | 7 May 2012 18:23

Re: Re: How to do this?

On May 7, 2012, at 12:03 PM, Steve Ropa wrote:

> Well, the first question in my mind is "Do you have a test for that?" In
> other words, did you write a test showing that the old functionality is
> correct, then write the new C# object in such a way as to make the test
> continue to pass? I have found that the act of writing those tests goes an
> incredibly long way toward understanding what the old code does. 

+1 on this.

One of the nice features of the .NET platform is the ease of interoperability between the supported languages.

I recently worked with a team that had an extensive legacy, untested VB.NET codebase. The strategy we took
was that any time we touched a file (with some exceptions), we wrote tests for it in C#, ensured that they
passed, ran the code through a VB -> C# converter, and then made the needed modifications using TDD.

In practice, it took some time to get used to this approach and it wasn't without it's hiccups, but over time,
more and more of the *useful* code became C# and was covered with tests.

---
Nayan Hajratwala - 734.658.6032 - http://agileshrugged.com -  <at> nhajratw

headers

Steven Gordon | 7 May 2012 18:38

Re: Re: How to do this?

If you try to just fix the old code, the temptation is to refactor methods
and the objects bottom up.  But, you are restricted by the structure of the
code, at least until you have enough of it rewritten with unit tests to be
able to refactor larger parts into more testable objects (for example,
getting rid of globals).  It is frustrating, and you have to live with bad
OO structure for quite a while before you drill up high enough to refactor
at a level where you really can get rid of duplication and other smells.
 Also, it takes a long time to drill up to the level where you can see what
the code is really trying to accomplish.

However, if you start by writing functional tests instead of unit tests,
then you can much more quickly learn what the code is really trying to do.
 You can much more quickly identify code that is doing the wrong thing (as
opposed to refactoring bottom-up code while preserving incorrect
functionality).  And if you get confident in functional test coverage of
the application, then you can do some refactoring without supporting unit
tests in order to get to a structure that is more amenable to bottom-up
introduction of unit tests.

The only downside of the functional test first approach is that sometimes
enough progress is made that the subsequent introduction of unit tests
seems to have less bang for the buck and sometimes never happens.

On Mon, May 7, 2012 at 9:03 AM, Steve Ropa <theropas <at> q.com> wrote:

> **
>
>
>
>

(Continue reading)

headers

Steve Ropa | 7 May 2012 19:22

RE: Re: How to do this?

It is definitely fun to be able to say "yes, Steve is right here".....

Functional tests would indeed be a better way to get the desired behavior
without having to get caught up in old design.  I would add that the
functional tests do not excuse us from writing new Unit Tests also for the
new C# code though.

-----Original Message-----
From: extremeprogramming <at> yahoogroups.com
[mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of Steven Gordon
Sent: Monday, May 07, 2012 10:38 AM
To: extremeprogramming <at> yahoogroups.com
Subject: Re: [XP] Re: How to do this?

If you try to just fix the old code, the temptation is to refactor methods
and the objects bottom up.  But, you are restricted by the structure of the
code, at least until you have enough of it rewritten with unit tests to be
able to refactor larger parts into more testable objects (for example,
getting rid of globals).  It is frustrating, and you have to live with bad
OO structure for quite a while before you drill up high enough to refactor
at a level where you really can get rid of duplication and other smells.
 Also, it takes a long time to drill up to the level where you can see what
the code is really trying to accomplish.

However, if you start by writing functional tests instead of unit tests,
then you can much more quickly learn what the code is really trying to do.
 You can much more quickly identify code that is doing the wrong thing (as
opposed to refactoring bottom-up code while preserving incorrect
functionality).  And if you get confident in functional test coverage of the
application, then you can do some refactoring without supporting unit tests

(Continue reading)

headers

Steven Gordon | 7 May 2012 20:24

Re: Re: How to do this?

On Mon, May 7, 2012 at 10:22 AM, Steve Ropa <theropas <at> q.com> wrote:

> **
>
>
> It is definitely fun to be able to say "yes, Steve is right here".....
>
> Functional tests would indeed be a better way to get the desired behavior
> without having to get caught up in old design. I would add that the
> functional tests do not excuse us from writing new Unit Tests also for the
> new C# code though.
>
Certainly not for any new code.  It can seem to make it not worth
retrofitting any old code with unit tests.

>
>
> -----Original Message-----
> From: extremeprogramming <at> yahoogroups.com
> [mailto:extremeprogramming <at> yahoogroups.com] On Behalf Of Steven Gordon
> Sent: Monday, May 07, 2012 10:38 AM
> To: extremeprogramming <at> yahoogroups.com
> Subject: Re: [XP] Re: How to do this?
>
> If you try to just fix the old code, the temptation is to refactor methods
> and the objects bottom up. But, you are restricted by the structure of the
> code, at least until you have enough of it rewritten with unit tests to be
> able to refactor larger parts into more testable objects (for example,
> getting rid of globals). It is frustrating, and you have to live with bad
> OO structure for quite a while before you drill up high enough to refactor

(Continue reading)

headers

Charlie Poole | 7 May 2012 20:33

Re: Re: How to do this?

In this case, assuming the OP goes ahead with a re-write, it's all new code.

On the issue of _whether_ it should be a rewrite, I'd incline toward the rewrite
in a situation where we are converting from VB to C#. Mostly that's because
I'll go to almost any length to avoid VB. 

For the option of incrementally converting parts of the code to C# while
maintaining the rest in VB, it seems to me that it adds another layer of
difficulty on top of what is already a difficult situation. We already have
somebody new to TDD and refactoring, a complex architecture and a lack
of tests. While working across two languages is not inodinately difficult
under .NET, there are numerous gotchas and it might complicate things
too much.

I'd vote for this as being one of those rare situations where a rewrite is
actually simpler.

Charlie

On Mon, May 7, 2012 at 11:24 AM, Steven Gordon <sgordonphd <at> gmail.com> wrote:
> On Mon, May 7, 2012 at 10:22 AM, Steve Ropa <theropas <at> q.com> wrote:
>
>> **
>>
>>
>> It is definitely fun to be able to say "yes, Steve is right here".....
>>
>> Functional tests would indeed be a better way to get the desired behavior
>> without having to get caught up in old design. I would add that the
>> functional tests do not excuse us from writing new Unit Tests also for the

(Continue reading)

headers

Wouter Lagerweij | 7 May 2012 12:38

Re: Re: How to do this?

Just to chime in on this theme: I've had a few projects that were complete
re-writes, and complete failures *until* the acceptance tests were written.
I eventually learned from those experiences, but it took a few of those
failures
It's much better for speed, quality, peace of mind, stress-levels and
company revenue to accept this, and spend time on *first* writing the tests.

Wouter

On Mon, May 7, 2012 at 9:25 AM, Steven Gordon <sgordonphd <at> gmail.com> wrote:

> One approach I have use to address both issues Paul points out (knowing the
> actual requirements and the need to unknot some code before you have any
> code that can support a unit test) is to instead start by automating
> acceptance tests.
>
> By first automating acceptance tests, you will learn what the actual
> requirements are.  You will also build a safety net that is likely to tell
> you whether or not the refactorings you do before good unit tests can be
> put in place broke the software.
>
> SteveG
>
> On Sun, May 6, 2012 at 11:18 PM, PAUL <beckfordp <at> btopenworld.com> wrote:
>
> > **
> >
> >
> >
> > Hi Thereasa,

(Continue reading)