开云体育

John,

Sorry for the delayed response... it has been a celebratory week for many in SE Michigan as GM and Ford are now very transparently (openly) embarked upon their respective Agility journeys.



"Sixteen years after folks like Ron Jeffries and Chet Hendrickson 'broke-ground' with the pursuit of XP at Chrysler... there is visible and tangible evidence of the durability and vitality of the contextualized pursuit of Agility within the Successful Large Enterprises of our region."

------------

Sounds like Ron & Chet are busy next week鈥� and I'll be working on integrating Scrum and PED鈥� so I'll link up with them the first week in July.

In the meantime鈥� I can point to a recent significant (for me) unit design (JUnit test) used in the pursuit of emerging (crafting) an effective mult-core API for the Java 7 Fork and Join Framework. [The "test"/functional code was iteratived during several months of refactoring.]

The code will remain at the following link for a few more days before an improved version (including asserts against the NUMBER_OF_BOOKINGS) is integrated into the PED reference application:



Output log results are available at:



Performance results are available at:




_Marvin

Roy -

My recollection is similar to yours, that test-first programming was the
earlier name for Test-Driven Development, and the process included
refactoring. I don't recall seeing the distinction "TFP => no refactoring"
until the last couple years, but maybe it's been used by some longer. Also,
there was another "test-first programming" that I now think came from Brian
Marick a few years before XP, that was suggesting writing all tests, then
writing the code (in contrast to the "little bit at a time" approach of
TDD).

I don't know that test-first programming was even an official name. I know
I was describing it as "incremental, test-first programming" ~2000 or 2001
(but not *naming* it that). There may have been another name or two
floating around too. The process definitely included the sense of testing,
coding, and refactoring.

I'm pretty sure Kent Beck gave the practice the "official" name
"Test-Driven Development" in the process of developing his TDD book (which
was published in 2002). He may have developed the "red-green-refactor"
cycle name then (or maybe someone else did and he picked it up, can't
remember). [I do remember somewhere back then, somebody from the UIUC crowd
having a two-billed hat they wore, labeled "code" and "refactoring" maybe,
for a demo at OOPSLA, I think - Brian Foote? Bill Opdyke?]

For me, I didn't "get" the granularity of the TDD process until I went to
the first XP Immersion class (1999?), though I think I'd seen Kent & Ward
giving a demo a couple years earlier where they wrote code in the debugger.
(Funny how easy it is to "see" the technology and not the process:)

--Bill

On Sun, Jun 24, 2012 at 9:44 AM, Roy Osherove <roy@...> wrote:

it's interesting. I've been in the agile community for about 10+ years now,
and only now does the difference between test=first and tdd come up (at
least for me), and refactoring is it.

have you always felt/knew this? where did you get this idea?

On Sun, Jun 24, 2012 at 2:01 PM, Steve Freeman <smgfreeman@...>
wrote:

**


On 21 Jun 2012, at 20:45, Roy Osherove wrote:

I don't get how test-first is not TDD, just related. test first, to me,
_is_ test-driven-development .
it is the basic essence of the practice.

didn't you once work for a company that made tools so that you didn't

have

to change the code to make it testable? I think that's the difference.

On Thu, Jun 21, 2012 at 6:05 PM, RonJeffries <ronjeffries@...>

wrote:

Test-first refers to the practice of writing a test before writing

code.

It is not the same as TDD, but strongly related.

--
Thanks,

Roy Osherove

- @RoyOsherove
- Author of "The Art Of Unit Testing" )

--

Bill Wake
Industrial Logic, Inc. @IndustrialLogic
Coaching | Training | Assessment | eLearning

Hi Roy

have you always felt/knew this? where did you get this idea?

I think it started to become apparent to me when i started seeing teams
were dancing the test first dance without leveraging it beyond the
technique.

I also think there is more to this then the mentioned "refactoring" element.
TDD to me includes the notion of letting you tests drives the way you write
code.
and apparently some teams can take this out of the equation while still
going through the notion of write a test, write a code and refactor.
(I think that power mocking mocking frameworks can help these teams sustain
this for quite some time)

Also as was mentioned TDD includes notions of letting the way you design
code change (what was referred here as emergent design)
and I also encountered teams (usually they are the same) that ignore this
while still going through the test first cycle.

Lior

it's interesting. I've been in the agile community for about 10+ years now,
and only now does the difference between test=first and tdd come up (at
least for me), and refactoring is it.

have you always felt/knew this? where did you get this idea?

On Sun, Jun 24, 2012 at 2:01 PM, Steve Freeman <smgfreeman@...> wrote:

**


On 21 Jun 2012, at 20:45, Roy Osherove wrote:

I don't get how test-first is not TDD, just related. test first, to me,
_is_ test-driven-development .
it is the basic essence of the practice.

didn't you once work for a company that made tools so that you didn't have
to change the code to make it testable? I think that's the difference.

On Thu, Jun 21, 2012 at 6:05 PM, RonJeffries <ronjeffries@...>

wrote:

Test-first refers to the practice of writing a test before writing code.
It is not the same as TDD, but strongly related.

--
Thanks,

Roy Osherove

- @RoyOsherove
- Author of "The Art Of Unit Testing" )
- My blog for team leaders:
- My favorite keyboard shortcuts:
- +972-524-655388 (GMT+2)


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

On Fri, Jun 22, 2012 at 8:54 PM, George Dinwiddie
<lists@...>wrote:

**
On 6/22/12 3:03 PM, Adam Sroka wrote:

The terms we use aren't always awesome, but various attempts to change
them by various well meaning people have not really improved the
situation to date. I am skeptical that there is anything real to be
gained.

I agree. And if people want to continue discussion about changing the
terms people use, please do it in Esperanto. ;-)

No, no� Ido!
--
J. B. Rainsberger :: ::



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

On Fri, Jun 22, 2012 at 3:48 PM, Russell Gold <russ@...> wrote:

**

At this point, you're really just making a fool of yourself.

Rudeness objection.
--
J. B. Rainsberger :: ::

On Thu, Jun 21, 2012 at 4:45 PM, Roy Osherove <roy@...> wrote:

I don't get how test-first is not TDD, just related. test first, to me,

_is_ test-driven-development .
it is the basic essence of the practice.

I find it convenient to distinguish "test first" (only rule: no production
code without a failing test) and "test driven" (test first + relentless
refactoring).
--
J. B. Rainsberger :: ::

On 21 Jun 2012, at 20:45, Roy Osherove wrote:

I don't get how test-first is not TDD, just related. test first, to me,
_is_ test-driven-development .
it is the basic essence of the practice.

didn't you once work for a company that made tools so that you didn't have to change the code to make it testable? I think that's the difference.

On Thu, Jun 21, 2012 at 6:05 PM, RonJeffries <ronjeffries@...> wrote:

Test-first refers to the practice of writing a test before writing code.
It is not the same as TDD, but strongly related.

Ah. that explains a lot.

On Sun, Jun 24, 2012 at 2:19 AM, Chet Hendrickson
<lists@...>wrote:

**


Hello Roy,

I believe that noise you heard was Kay's joke whizzing over your head.

chet


Saturday, June 23, 2012, 3:38:40 PM, you wrote:

Box behind the CPU ? A physical one? A dialog box? CPU==IDE?
And no that is not what I know boxing and unboxing to be(value types vs
objects)

So I am lost

Can you make a video of how you work?

On Saturday, June 23, 2012, Kay A Pentecost wrote:

**

Hey, Chet,

Since I get a *lot* of compiler errors, I've placed a small box behind

the

CPU to catch them. The regular errors go in there, too. I've found the
small amount of dust that also accumulates can be easily blown away.

Once

the box is filled, I blow away any dust, and empty the box into the CPU.

I haven't found that the recycled errors mix themselves up at all. I

don't

see code errors popping up as system errors or compiler errors as code
errors; they recycle like stem cells.

I'm working in C# now. I believe this is called "boxing and unboxing,"

but

I call it Digital Error Environment Process (DEEP). I'm thinking of

adding

the term "System Handling Integral Technique" to it, and I'm working on

a

white paper.

I happily give you (and the list members) permission to use this

technique

in the beta form, as long as you credit me and use the correct

terminology

so everyone will think I'm more brilliant and creative than I actually

am.

I've learned all this from the work I've done with VSIPC.

Kay Pentecost

--
Best regards,
Chet Hendrickson mailto:lists@...
Check out our upcoming CSM Plus courses @

--
Thanks,

Roy Osherove

- @RoyOsherove
- Author of "The Art Of Unit Testing" )
- My blog for team leaders:
- My favorite keyboard shortcuts:
- +972-524-655388 (GMT+2)


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

Hello Roy,

I believe that noise you heard was Kay's joke whizzing over your head.

chet

Saturday, June 23, 2012, 3:38:40 PM, you wrote:

--
Best regards,
Chet Hendrickson mailto:lists@...
Check out our upcoming CSM Plus courses @

Box behind the CPU ? A physical one? A dialog box? CPU==IDE?
And no that is not what I know boxing and unboxing to be(value types vs
objects)

So I am lost

Can you make a video of how you work?

On Saturday, June 23, 2012, Kay A Pentecost wrote:

**


Hey, Chet,

Since I get a *lot* of compiler errors, I've placed a small box behind the
CPU to catch them. The regular errors go in there, too. I've found the
small amount of dust that also accumulates can be easily blown away. Once
the box is filled, I blow away any dust, and empty the box into the CPU.

I haven't found that the recycled errors mix themselves up at all. I don't
see code errors popping up as system errors or compiler errors as code
errors; they recycle like stem cells.

I'm working in C# now. I believe this is called "boxing and unboxing," but
I call it Digital Error Environment Process (DEEP). I'm thinking of adding
the term "System Handling Integral Technique" to it, and I'm working on a
white paper.

I happily give you (and the list members) permission to use this technique
in the beta form, as long as you credit me and use the correct terminology
so everyone will think I'm more brilliant and creative than I actually am.

I've learned all this from the work I've done with VSIPC.

Kay Pentecost

-----Original Message-----
From: testdrivendevelopment@... <javascript:_e({}, 'cvml',

'testdrivendevelopment%40yahoogroups.com');>

[mailto:testdrivendevelopment@... <javascript:_e({},

'cvml', 'testdrivendevelopment%40yahoogroups.com');>] On Behalf Of Chet

Hendrickson
Sent: Saturday, June 23, 2012 9:25 AM
To: testdrivendevelopment@... <javascript:_e({}, 'cvml',

'testdrivendevelopment%40yahoogroups.com');>

Subject: Re: [TDD] Re: Cunningham quote about test-first

Hello Marvin,

I am struck by your commit regarding cluttering the workspace with
compiler errors. Clutter is, of course, a rather non specific measure of
compiler errors, however, in my experience I have not seen TDD lead to

any

quantity of compiler errors that I would consider clutter. This comment
and several other in the course of this thread has lead me to believe

that

your mental picture of TDD and mine are quite different.

The only example of your code I have seen is the PED reference app. Did
you write that with what you consider TDD?

chet

Saturday, June 23, 2012, 6:32:33 AM, you wrote:



Kay,

I made up the terms "strict sequencing" and "relaxed sequencing". They

are

loosely inspired by the architectural notions of "strict layering" and
"relaxed layering".

Through the years it has been my observation that there are some that
consider 'strictly' writing a test class first... even if it clutters the
workspace with compiler errors... to be critical. Said another way, that
it is a necessary dependency for emerging (crafting) a good design to
endure the IDE noise.

There are others that take a more relaxed view... I think Nayan coined

the

term Production Stub Driven Tests (PSDT) and asserted it is *not*
consistent with TDD.

For me... I'm OK with those that want strict sequencing... and I'm OK

with

those that don't want the IDE barking at them... in either case I remain
hopeful that the focus on emergent (or crafted) design is the meaningful
common ground.

_Marvin


--- In testdrivendevelopment@... <javascript:_e({}, 'cvml',

'testdrivendevelopment%40yahoogroups.com');>, "Kay A Pentecost" <kayp@...>

wrote:

Let me know when you find a place where Ron said "strict sequencing"

was

important to him.

Thanks,
Kay

--
Best regards,
Chet Hendrickson mailto:lists@... <javascript:_e({},

'cvml', 'lists%40hendricksonxp.com');>

Check out our upcoming CSM Plus courses @


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



------------------------------------

Yahoo! Groups Links

--
Thanks,

Roy Osherove

- @RoyOsherove
- Author of "The Art Of Unit Testing" )
- My blog for team leaders:
- My favorite keyboard shortcuts:
- +972-524-655388 (GMT+2)


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

Hey, Chet,

Since I get a *lot* of compiler errors, I've placed a small box behind the
CPU to catch them. The regular errors go in there, too. I've found the
small amount of dust that also accumulates can be easily blown away. Once
the box is filled, I blow away any dust, and empty the box into the CPU.

I haven't found that the recycled errors mix themselves up at all. I don't
see code errors popping up as system errors or compiler errors as code
errors; they recycle like stem cells.

I'm working in C# now. I believe this is called "boxing and unboxing," but
I call it Digital Error Environment Process (DEEP). I'm thinking of adding
the term "System Handling Integral Technique" to it, and I'm working on a
white paper.

I happily give you (and the list members) permission to use this technique
in the beta form, as long as you credit me and use the correct terminology
so everyone will think I'm more brilliant and creative than I actually am.

I've learned all this from the work I've done with VSIPC.

Kay Pentecost

Hello John,

The Brighton Agile Roundtable would be happy to have you. We will be away next week. Let us know when you would like to drop by. We meet most mornings.

chet

Saturday, June 23, 2012, 11:04:35 AM, you wrote:



Marvin, you really need to take Ron up on his offer and meet with him for
clarification and some learning. Ron, I'll be spending a week here and
there in Troy, MI with a client over the next few months. If Marvin
doesn't take you up on your offer, can *I* ? :-)

(sent from my Droid)

--
Best regards,
Chet Hendrickson mailto:lists@...
Check out our upcoming CSM Plus courses @

Marvin, you really need to take Ron up on his offer and meet with him for
clarification and some learning. Ron, I'll be spending a week here and
there in Troy, MI with a client over the next few months. If Marvin
doesn't take you up on your offer, can *I* ? :-)

(sent from my Droid)

Hello Marvin,

I am struck by your commit regarding cluttering the workspace with compiler errors. Clutter is, of course, a rather non specific measure of compiler errors, however, in my experience I have not seen TDD lead to any quantity of compiler errors that I would consider clutter. This comment and several other in the course of this thread has lead me to believe that your mental picture of TDD and mine are quite different.

The only example of your code I have seen is the PED reference app. Did you write that with what you consider TDD?

chet

Saturday, June 23, 2012, 6:32:33 AM, you wrote:



Kay,

I made up the terms "strict sequencing" and "relaxed sequencing". They are loosely inspired by the architectural notions of "strict layering" and "relaxed layering".

Through the years it has been my observation that there are some that consider 'strictly' writing a test class first... even if it clutters the workspace with compiler errors... to be critical. Said another way, that it is a necessary dependency for emerging (crafting) a good design to endure the IDE noise.

There are others that take a more relaxed view... I think Nayan coined the term Production Stub Driven Tests (PSDT) and asserted it is *not* consistent with TDD.

For me... I'm OK with those that want strict sequencing... and I'm OK with those that don't want the IDE barking at them... in either case I remain hopeful that the focus on emergent (or crafted) design is the meaningful common ground.

_Marvin

--
Best regards,
Chet Hendrickson mailto:lists@...
Check out our upcoming CSM Plus courses @

Kay,

I made up the terms "strict sequencing" and "relaxed sequencing". They are loosely inspired by the architectural notions of "strict layering" and "relaxed layering".

Through the years it has been my observation that there are some that consider 'strictly' writing a test class first... even if it clutters the workspace with compiler errors... to be critical. Said another way, that it is a necessary dependency for emerging (crafting) a good design to endure the IDE noise.

There are others that take a more relaxed view... I think Nayan coined the term Production Stub Driven Tests (PSDT) and asserted it is *not* consistent with TDD.

For me... I'm OK with those that want strict sequencing... and I'm OK with those that don't want the IDE barking at them... in either case I remain hopeful that the focus on emergent (or crafted) design is the meaningful common ground.

_Marvin

Hello George,

plus unu

chet

Friday, June 22, 2012, 7:54:59 PM, you wrote:



Adam,

On 6/22/12 3:03 PM, Adam Sroka wrote:

The terms we use aren't always awesome, but various attempts to change
them by various well meaning people have not really improved the
situation to date. I am skeptical that there is anything real to be
gained.

I agree. And if people want to continue discussion about changing the
terms people use, please do it in Esperanto. ;-)

- George

--
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------






--
Best regards,
Chet Hendrickson mailto:lists@...
Check out our upcoming CSM Plus courses @

Adam,

On 6/22/12 3:03 PM, Adam Sroka wrote:

The terms we use aren't always awesome, but various attempts to change
them by various well meaning people have not really improved the
situation to date. I am skeptical that there is anything real to be
gained.

I agree. And if people want to continue discussion about changing the terms people use, please do it in Esperanto. ;-)

- George

--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------

Marvin:

On Fri, Jun 22, 2012 at 11:56 AM, Buddha Buck <blaisepascal@...> wrote:

On Fri, Jun 22, 2012 at 2:48 PM, Russell Gold <russ@...> wrote:

Marvin,

Ron saying that "you should start with [Kent] if you think the names
should be changed" is not the same as saying that "it is a good idea to ask
Kent."

That somebody has the sole authority to do X does not mean that it is a
good idea to ask that X be done.

I would even argue that Kent doesn't have the sole authority to change
the name of TDD now. He coined it, but I think even he'd face some
serious scepticism if he suggested changing it now.

Without presuming to speak for him, I would wager that it is a
responsibility he neither wants nor would accept.

The terms we use aren't always awesome, but various attempts to change
them by various well meaning people have not really improved the
situation to date. I am skeptical that there is anything real to be
gained.