Discussion:
Carnegie Mellon to the rescue...
Phlip
2004-07-27 21:48:09 UTC
Permalink
http://www.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html

This is so amazing. It reminds me of psychiatrists who
neglect the study of happy & well-adjusted people.

"But help is on the way. Myers and a graduate student,
Andrew Ko, have developed a debugging program that
lets users ask questions about computer errors in
plain English: Why didn't a program behave as
expected?

"Funded by $1.2 million from the National Science
Foundation..."

So, an acceptance test framework like FIT is supposed
to answer, in English, what a program's behavior does.
But FIT doesn't cost 1.2 million, so it doesn't show
up in the news...

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-07-27 23:37:09 UTC
Permalink
Post by Phlip
http://www.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html
This is so amazing. It reminds me of psychiatrists who
neglect the study of happy & well-adjusted people.
And,
"Adding Whyline to a different language, like Java, which is 10
times as complex, could limit how much Whyline can help."

Great. Lotta' help that is!

And Test Driven Development (TDD), properly followed, dramatically
reduces the problem.

_ _ _


I understand that XP shops don't have that much of a need for
debuggers, but I'm still in the dark ages, ;-> and I was really
impressed by Retro Vue, a "logging debugger" I saw at JavaOne:

http://www.visicomp.com

Essentially, it single-steps through your program as it runs, and
logs everything that happens. This takes a lot of disk space, but
you can scroll forward and backward through "time," to see and query
on anything that happened during the run. Like, "What were all the
previous values of this variable, and where and when were they set?"

Most interesting. I can think of several times I could really have
used it.

(I'm not associated with them in any way. I just found their
product cool.)



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2004-07-27 23:51:41 UTC
Permalink
From: "Jeff Grigg" <***@yahoogroups.at.jhrothjr.com>
Sent: Tuesday, July 27, 2004 7:37 PM
Subject: [XP] Re: Carnegie Mellon to the rescue... (or TDD, or existing
tools!!!)
Post by Jeff Grigg
Post by Phlip
http://www.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html
This is so amazing. It reminds me of psychiatrists who
neglect the study of happy & well-adjusted people.
And,
"Adding Whyline to a different language, like Java, which is 10
times as complex, could limit how much Whyline can help."
Great. Lotta' help that is!
And Test Driven Development (TDD), properly followed, dramatically
reduces the problem.
_ _ _
I understand that XP shops don't have that much of a need for
debuggers, but I'm still in the dark ages, ;-> and I was really
http://www.visicomp.com
Essentially, it single-steps through your program as it runs, and
logs everything that happens. This takes a lot of disk space, but
you can scroll forward and backward through "time," to see and query
on anything that happened during the run. Like, "What were all the
previous values of this variable, and where and when were they set?"
Most interesting. I can think of several times I could really have
used it.
Yeah. This is one of those things where you don't usually
need a tool, but when you need it, you need it real bad.
You also need the best tool you can get your hands on.

John Roth




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ilja Preuss
2004-07-28 08:44:37 UTC
Permalink
Post by Jeff Grigg
I understand that XP shops don't have that much of a need for
debuggers, but I'm still in the dark ages, ;-> and I was really
http://www.visicomp.com
CodeGuide seems to have a similar feature:
http://www.omnicore.com/debugger.htm

Cheers, Ilja



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-28 19:59:14 UTC
Permalink
Post by Jeff Grigg
I understand that XP shops don't have that much of
a need for debuggers
XP teams leverage every (cheap) tool available - UML,
whiteboards, tests, pairing, form painters, code
wizards, and debuggers - to avoid debuggING.


=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-28 20:59:34 UTC
Permalink
Post by Phlip
Post by Jeff Grigg
I understand that XP shops don't have that much of
a need for debuggers
XP teams leverage every (cheap) tool available - UML,
whiteboards, tests, pairing, form painters, code
wizards, and debuggers - to avoid debuggING.
It's like the commercial says:
"a day without my Pops is like a day without setting a breakpoint."




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Victor
2004-07-28 21:24:43 UTC
Permalink
All depends on the language used. In Smalltalk, the debugger is organically
integrated with SUnit, and is indeed very useful.

Victor

=============================

----- Original Message -----
From: "Ken Boucher" <***@nozen.com>
To: <***@yahoogroups.com>
Sent: Wednesday, July 28, 2004 4:59 PM
Subject: [XP] Re: Carnegie Mellon to the rescue... (or TDD, or existing
tools!!!)
Post by Ken Boucher
Post by Phlip
Post by Jeff Grigg
I understand that XP shops don't have that much of
a need for debuggers
XP teams leverage every (cheap) tool available - UML,
whiteboards, tests, pairing, form painters, code
wizards, and debuggers - to avoid debuggING.
"a day without my Pops is like a day without setting a breakpoint."
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-07-28 21:27:27 UTC
Permalink
Post by Phlip
Post by Jeff Grigg
I understand that XP shops don't have that much of
a need for debuggers
XP teams leverage every (cheap) tool available - UML,
whiteboards, tests, pairing, form painters, code
wizards, and debuggers - to avoid debuggING.
A few months ago, we had a "fishbowl" coding session at the XPSTL
user group, with members of the audience switching off with the pair
programming using a projector. As I was coding one of the stories,
we (us, the pair, and most of the audience) got into a disagreement
as to /why/ a particular test was failing. And you have to know
what's wrong before you can fix it. So I set a breakpoint in the
test and ran the Eclipse debugger. *GASPS!* throughout the room! ;-
Post by Phlip
"Why are you using the debugger?" several people demanded. I
ignored the comments while I single stepped into the code. This
showed which path the code was taking and why. End of argument. Now
we *knew* why the test was failing, and could easily fix it.

But I agree: XP teams generally avoid integration hell and debugger
nightmares -- most of the time. However, sometimes a debugger can
still be a useful tool, even in an XP shop.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-28 21:56:29 UTC
Permalink
...So I set a
breakpoint in the
test and ran the Eclipse debugger. *GASPS!*
throughout the room! ;-
Post by Phlip
"Why are you using the debugger?" several people
demanded. I
ignored the comments while I single stepped into the
code. This
showed which path the code was taking and why. End
of argument. Now
we *knew* why the test was failing, and could easily
fix it.
But I agree: XP teams generally avoid integration
hell and debugger
nightmares -- most of the time. However, sometimes
a debugger can
still be a useful tool, even in an XP shop.
When refactoring, an unexpected Red Bar is cause to
hit Undo, not bother to inspect why something failed.
(A few Red Bars in a row should raise that
suspicion...)

When TDD-ing, you write a test and ensure it fails for
the correct reason. Your assertions must carefully
explain the failure. (And a spectacular crash, with no
explanations, if predicted, can also be a "correct
reason"!)

So debugging around TDD is healthier than around refactoring.

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 01:04:10 UTC
Permalink
Post by Phlip
When refactoring, an unexpected Red Bar is cause to
hit Undo, not bother to inspect why something failed.
(A few Red Bars in a row should raise that
suspicion...)
I'm sorry, but I have to disagree with this. If I red bar while
refactoring I want to know WHY. Is there something about the code I'm
not understanding? (If so I want to understand it.) Is there
something about the Unit test that might be worth a closer look at.
(Yes, it's shocking but I have found (*gasp*) unit tests with errors
in them.)





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 01:09:41 UTC
Permalink
Post by Ken Boucher
Post by Phlip
When refactoring, an unexpected Red Bar is cause to
hit Undo, not bother to inspect why something failed.
(A few Red Bars in a row should raise that
suspicion...)
I'm sorry, but I have to disagree with this. If I red bar while
refactoring I want to know WHY. Is there something about the code I'm
not understanding? (If so I want to understand it.) Is there
something about the Unit test that might be worth a closer look at.
(Yes, it's shocking but I have found (*gasp*) unit tests with errors
in them.)
Have you tried just undoing for a while? It's kind of an interesting
experience.

Ron Jeffries
www.XProgramming.com
A firkin is 9 imperial gallons, or 40.905 liters, or
81.81 half-liter cans, allowing for 5.8 cans per day over two weeks.
Therefore, a firkin per fortnight is a six-pack per day.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-29 01:50:14 UTC
Permalink
Post by Phlip
Post by Phlip
When refactoring, an unexpected Red Bar is cause
to
Post by Phlip
hit Undo, not bother to inspect why something
failed.
Post by Phlip
(A few Red Bars in a row should raise that
suspicion...)
I'm sorry, but I have to disagree with this. If I
red bar while
refactoring I want to know WHY. Is there something
about the code I'm
not understanding? (If so I want to understand it.)
Is there
something about the Unit test that might be worth a
closer look at.
(Yes, it's shocking but I have found (*gasp*) unit
tests with errors
in them.)
Between each time you hit the test button, all changes
should be so trivial that you could back them out
manually, _without_ the Undo button.

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 02:45:50 UTC
Permalink
Post by Phlip
Between each time you hit the test button, all changes
should be so trivial that you could back them out
manually, _without_ the Undo button.
This is where I get confused.

See, the code base I work with is getting rather large. And one thing
is often related to some other thing. In fact that some other thing
may be miles away. The removal of what appears to be duplication
between two objects may involve running just the tests for those two
objects but some obscure behavior change may actually be reflected in
a third test case that I wasn't thinking about at the time.

Now your entire test sweet may run in minutes. Ours, unfortunately,
takes half an hour on a good day. So, for obvious reasons, I'm not
running the entire test sweet after only changing a method or two.

So I'm hoping you can understand why I'm not hitting the test button
every time I do some trivial change. I'm much more likely to run our
product's portion of the test suite while taking a bathroom break and
running the entire test suite when releasing code, heading off to
lunch, or going home for the day.

Now sure, people may think that 30 minutes for a test suite is too
long, but a couple years of coding by a roomful of people tends to be
a heck of a lot of code to run on the machine you're coding on.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Joshua Kerievsky
2004-07-29 03:02:30 UTC
Permalink
Post by Ken Boucher
Now sure, people may think that 30 minutes for a test suite is too
long, but a couple years of coding by a roomful of people tends to be
a heck of a lot of code to run on the machine you're coding on.
Test speed. It's soo darned critical, I'd now say that if you are about
to set off on a multi-year, multi-person gig, You *Are* Gonna Need It.
So do whatever upfront work is necessary to ensure that everyone writes
test that execute quickly and keep a constant eye on making sure the
tests continue to run quickly. If they begin to run slowly, stop
everything, profile the tests and find ways to make them run faster
(including throwing hardware at the problem).

For your immediate situation, could you begin to attack test speed
slowly but surely for the next 4-6 months?

best
jk



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-29 03:16:07 UTC
Permalink
...If they begin to run
slowly, stop
everything, profile the tests and find ways to make
them run faster
(including throwing hardware at the problem).
Hypothesis: A blue-sky project, with limited
involvement in legacy libraries, will emerge
super-fast testage. Nobody will remember a time they
stopped to tune them.

The production code will grow so decoupled that all
tests never pull in extra stuff.

Hypothesis 2: You aren't going to need a blue-sky
project. ;-)

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Joshua Kerievsky
2004-07-29 04:42:23 UTC
Permalink
Post by Phlip
Hypothesis: A blue-sky project, with limited
involvement in legacy libraries, will emerge
super-fast testage. Nobody will remember a time they
stopped to tune them.
One XP team I worked with in 2000, which had only been doing development
for a few months before I joined them, was having trouble with the speed
of tests that involved their database. We eventually refactored the
code to use the Repository pattern (see Fowler's Patterns of Enterprise
Application Architectures). Using a Repository helped us solve several
design problems, so we didn't do it just to make the tests run faster.

At a conference later that year, I spoke with some folks who said they
used an equivalent of the Repository pattern very early on in their
projects specifically to avoid having database tests run too slowly. I
dismissed the idea at the time, as it seemed like too much upfront
work. Now I'm not so sure. It's not so much that we abandon
minimalism, YAGNI, etc. It's more an issue of that test speed trumps a
lot of other stuff because it is so darned important.

best
jk



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-29 04:56:55 UTC
Permalink
Post by Joshua Kerievsky
... I
dismissed the idea at the time, as it seemed like
too much upfront
work. Now I'm not so sure. It's not so much that
we abandon
minimalism, YAGNI, etc. It's more an issue of that
test speed trumps a
lot of other stuff because it is so darned
important.
In 1999, Kent Beck pointed out on the XP mailing list
we wouldn't keep complaining that databases are slow
to test and horrible to refactor if the vendors had
used test-first to invent them...

Pure formalism, based on emergent principles, is fun.
But facts on the ground, we need a long list of
proactive effort to mimize reasons not to hit the test
button. YAGNI applies to production code, not
(strictly) to the entire development around it.

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-30 17:44:41 UTC
Permalink
Post by Joshua Kerievsky
At a conference later that year, I spoke with some folks who said they
used an equivalent of the Repository pattern very early on in their
projects specifically to avoid having database tests run too slowly. I
dismissed the idea at the time, as it seemed like too much upfront
work. Now I'm not so sure. It's not so much that we abandon
minimalism, YAGNI, etc. It's more an issue of that test speed trumps a
lot of other stuff because it is so darned important.
An open question:

My #1 testing goal is to be able to test every single object in complete
isolation from the implementation details of its collaborators--that is,
nothin' but interfaces. The result of achieving 95%+ of this goal is 100
tests per second, or 60,000 tests in 10 minutes. When would you rather
hit the 10-minute upper limit? In two months (done it) or in two years
(meaning, for many projects, never)? How much time are you willing to
spend putting off that problem for six to twelve person-years?

Design debt is about paying now /and/ later for the shortcut you took
today. It's borrowing from the future to pay the present and it kills us.

This one goal is about amortizing the cost of effort now over time for
something that saves the team hours per day over months. There's no
thinking required there; I just do it.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-30 20:14:25 UTC
Permalink
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single object in complete
isolation from the implementation details of its collaborators--that is,
nothin' but interfaces.
I see the value of this. But I have a fear. Do you find that you get into
integration problems very frequently, where two or more classes are passing
their isolated tests but don't play well together? What's your experience
and practice on that?

Ron Jeffries
www.XProgramming.com
Bazen and an Engineer were out walking together. Bazen turned to the
Engineer and said, "Tell me Engineer, what is the sound of one hand
clapping?" The Engineer, swatting at the air near one ear, replied "It's
sort of a 'wooshing' noise, isn't it?" At this, Bazen was enlightened.
--Mr. Ed, of hacknot




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-30 20:44:38 UTC
Permalink
Post by Ron Jeffries
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single object in complete
isolation from the implementation details of its collaborators--that is,
nothin' but interfaces.
I see the value of this. But I have a fear. Do you find that you get into
integration problems very frequently, where two or more classes are passing
their isolated tests but don't play well together? What's your experience
and practice on that?
Hm. I don't remember this ever happening. (Different from "This has
never happened".) I imagine that if this /did/ happen, then I guess
there are two possible problems.

1. Some implementation of B doesn't implement B's contract correctly, so
when A relies on that implementation of B, the integration fails.

SOLUTION: Create an Abstract Test Case for B's contract, then subject
all implementations of B to those tests.

2. Some test for A depends on behavior of B that doesn't conform to B's
contract.

SOLUTION: Splash cold water on face. Fix the broken test. Ask my pair
why he let me do that, or beg for a pair, whichever is appropriate.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-30 21:26:10 UTC
Permalink
Post by J. B. Rainsberger
Post by Ron Jeffries
I see the value of this. But I have a fear. Do you find that you get into
integration problems very frequently, where two or more classes are passing
their isolated tests but don't play well together? What's your experience
and practice on that?
Hm. I don't remember this ever happening. (Different from "This has
never happened".)
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
Post by J. B. Rainsberger
I imagine that if this /did/ happen, then I guess
there are two possible problems.
Yes, approaches good. Was concerned whether it happened often enough to
care. I gather for you the answer is no. Cool.

Ron Jeffries
www.XProgramming.com
If you're not throwing some gravel once in a while,
you're not using the whole road.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-30 21:33:34 UTC
Permalink
Post by Ron Jeffries
Post by J. B. Rainsberger
Post by Ron Jeffries
I see the value of this. But I have a fear. Do you find that you get into
integration problems very frequently, where two or more classes are passing
their isolated tests but don't play well together? What's your experience
and practice on that?
Hm. I don't remember this ever happening. (Different from "This has
never happened".)
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
We use a similar approach to what J.B. describes and it has rarely, if
ever, caused us any problems either (I also can't remember any specific
instances where this has happened). The benefits in test speed have
been significant.

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-30 21:51:20 UTC
Permalink
Post by Steve Bate
Post by Ron Jeffries
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
We use a similar approach to what J.B. describes and it has rarely, if
ever, caused us any problems either (I also can't remember any specific
instances where this has happened). The benefits in test speed have
been significant.
Very interesting indeed.

Ron Jeffries
www.XProgramming.com
Most peculiar, mama. -- John Lennon (nr)




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-30 21:34:37 UTC
Permalink
Post by Ron Jeffries
Post by J. B. Rainsberger
Post by Ron Jeffries
I see the value of this. But I have a fear. Do you find that you get into
integration problems very frequently, where two or more classes are passing
their isolated tests but don't play well together? What's your experience
and practice on that?
Hm. I don't remember this ever happening. (Different from "This has
never happened".)
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
Mind you, my experience comes principally from solo projects, and one
needn't communicate much with oneself.
Post by Ron Jeffries
Yes, approaches good. Was concerned whether it happened often enough to
care. I gather for you the answer is no. Cool.
So far, so good.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
George Dinwiddie
2004-07-31 03:00:43 UTC
Permalink
Post by Ron Jeffries
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
Not necessarily. If you test the interfaces of higher level objects
*without* mocking the lower level objects on which they depend, you're
not likely to run into such problems.

Mock objects are seductive, because they make things easier. In my own
experience, and in my observations of people whom I've worked with, a
typical pattern is to fall in love with mocks once you've learned how to
work them, and then to back off on their use as you run into the kinds
of difficulties that you worry about.

I now tend to use mocks
- to break my test dependency on systems (3rd party, other teams,
databases, etc.) outside of my control. I use these mocks to specify
the behavior I expect from these systems. If I can't mock the systems
themselves, I wrap them in an abstraction layer and mock the abstraction
layer. I find this enormously useful in (all too common) situations
where the other system is not amenable to testing. In the case of
databases, it's mostly a matter of speed. I also test the other side of
the equation, my persistence layer down to the actual database, in a
separate suite of tests that I run less frequently (several times a day
rather than every minute or two) because of the time it takes.
- temporarily to help me work out my strategy for a problem.
Sometimes I don't know what API I want for lower level objects, so I use
mocks while developing upper levels to see what it wants. As it becomes
clear, the mocks get fleshed out into real objects and moved to the
source tree from the test tree.

I also create fake clients for the code under test, but I'm moving to a
pattern of calling these "example" objects rather than "mock" objects.

- George
--
----------------------------------------------------------------------
When I remember bygone days George Dinwiddie
I think how evening follows morn; ***@alberg30.org
So many I loved were not yet dead, http://www.Alberg30.org
So many I love were not yet born.
'The Middle' by Ogden Nash
----------------------------------------------------------------------





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-31 11:23:22 UTC
Permalink
Post by George Dinwiddie
Post by Ron Jeffries
This is the part I was worried about, whether it happens often enough that
one would notice. I'm often leery of the approach of mocking everything
(which I guess you must be doing a lot) because of this fear ...
Not necessarily. If you test the interfaces of higher level objects
*without* mocking the lower level objects on which they depend, you're
not likely to run into such problems.
Mock objects are seductive, because they make things easier. In my own
experience, and in my observations of people whom I've worked with, a
typical pattern is to fall in love with mocks once you've learned how to
work them, and then to back off on their use as you run into the kinds
of difficulties that you worry about.
Yes, that's why I'm so interested in hearing that JB is having good results
while testing objects almost exclusively in isolation. I'd expect trouble
to arise for him, and so far it hasn't.

One might think that good isolated unit testing could avoid integration
problems. Then, for me and I guess for you, we find that it doesn't. JB's
no beginner, and yet the unit testing is holding for him. I'm interested
and curious.
Post by George Dinwiddie
I now tend to use mocks
- to break my test dependency on systems (3rd party, other teams,
databases, etc.) outside of my control. I use these mocks to specify
the behavior I expect from these systems. If I can't mock the systems
themselves, I wrap them in an abstraction layer and mock the abstraction
layer. I find this enormously useful in (all too common) situations
where the other system is not amenable to testing. In the case of
databases, it's mostly a matter of speed. I also test the other side of
the equation, my persistence layer down to the actual database, in a
separate suite of tests that I run less frequently (several times a day
rather than every minute or two) because of the time it takes.
- temporarily to help me work out my strategy for a problem.
Sometimes I don't know what API I want for lower level objects, so I use
mocks while developing upper levels to see what it wants. As it becomes
clear, the mocks get fleshed out into real objects and moved to the
source tree from the test tree.
I also create fake clients for the code under test, but I'm moving to a
pattern of calling these "example" objects rather than "mock" objects.
Good examples all. I'd like to see an example of the "temporarily" ones as
APIs shape up. I may be doing something similar, as I work very top down,
but I don't often use what I'd call mocks or even stub objects. At least I
think I don't ...

(Are you using the term "mock" here in its more formal sense, or more in
the sense of stub?)

I guess JB needs to write some papers about this. Get on it, JB! :)

Ron Jeffries
www.XProgramming.com
You are closing your eyes to a situation you do not wish to acknowledge.
--Professor Harold Hill




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-31 14:32:22 UTC
Permalink
Post by Ron Jeffries
I guess JB needs to write some papers about this. Get on it, JB! :)
!? I just finished writing a damn book on the subject! It's a shame
you're so allergic to Java....
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-31 17:44:17 UTC
Permalink
Post by J. B. Rainsberger
Post by Ron Jeffries
I guess JB needs to write some papers about this. Get on it, JB! :)
!? I just finished writing a damn book on the subject! It's a shame
you're so allergic to Java....
Where's my copy? Is it in print yet?

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




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-31 14:38:55 UTC
Permalink
Post by Ron Jeffries
One might think that good isolated unit testing could avoid integration
problems. Then, for me and I guess for you, we find that it doesn't. JB's
no beginner, and yet the unit testing is holding for him. I'm interested
and curious.
Mind you, I /believe/ that thorough, isolated object testing has been
enough for me. I would like to see someone with real testing skill
hammer away at something I've done recently and show me how incredibly
porous it really is. (Fortunately, I know just the fellow, and I know he
has time on his hands.) At most, for now, I can say, "So far, so good."
Post by Ron Jeffries
Post by George Dinwiddie
I also create fake clients for the code under test, but I'm moving to a
pattern of calling these "example" objects rather than "mock" objects.
Interestingly, I have also called many of these "alternate
implementations", although I like the term "example".

For example--pun intended--I may have a Repository interface. When I
implement this completely in memory, for testing purposes, this is not a
fake, and not a mock, but rather, an alternate implementation. It is a
full-bore in-memory Repository, and it would be production worthy if it
weren't for this story here that says, "I want to be able search among
all the forms ever submitted in the system," which seems to imply a
certain kind of persistence. :)

You can read a story about how I did this in the past--about 2001 while
at IBM--in Better Software Magazine's April 2004 edition. I first used
an in-memory Repository (though I didn't call it that then) to drive the
design of the object model, then a few weeks before release, implemented
the RDBMS implementation to talk to our master database. Only then did I
create the database schema to support it. It worked quite well for me.

Nowadays, I tend to mock the Repository interface, writing
"interaction-based" tests in the Thoughtworks parlance, assuming that I
understand the distinction correctly. I find it unusual for an alternate
implementation to be less work than writing the corresponding
interaction-based tests.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-31 15:07:14 UTC
Permalink
Post by J. B. Rainsberger
Mind you, I /believe/ that thorough, isolated object testing has been
enough for me. I would like to see someone with real testing skill
hammer away at something I've done recently and show me how incredibly
porous it really is. (Fortunately, I know just the fellow, and I know he
has time on his hands.) At most, for now, I can say, "So far, so good."
Hi J.B.,

IIRC, one of your recent applications was web based. Did you have higher
level "integration" tests for ensuring proper configuration of the web
server (e.g. correct web application descriptors and packaging) or
are these tested manually? I'm assuming (because of the test execution
speed) that your isolated tests don't access an external database. If
you were using an RDBMS, for example, how would you ensure the
application code and database schema are consistent with each other?

We have two categories of tests: unit and functional. The unit tests
are strict isolation tests. The functional tests include both customer
acceptance tests and programmer-originated integration tests for
functionality where it's difficult or impossible to do isolated testing.

The fast unit tests meet most of our testing needs while the much slower
functional tests fill the need for integration testing (usually with
external, third party systems like messaging middleware and databases).
How do you do the latter types of testing?

You mentioned that you have been using your techniques with a very
small team and wasn't sure how it would scale. Our team has been using
the strict mock-based unit testing for several years now with a team
whose size has ranged from 5 to 20 developers and we've had excellent
results.

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-08-02 16:16:41 UTC
Permalink
Post by Steve Bate
Post by J. B. Rainsberger
Mind you, I /believe/ that thorough, isolated object testing has been
enough for me. I would like to see someone with real testing skill
hammer away at something I've done recently and show me how incredibly
porous it really is. (Fortunately, I know just the fellow, and I know he
has time on his hands.) At most, for now, I can say, "So far, so good."
Hi J.B.,
IIRC, one of your recent applications was web based. Did you have higher
level "integration" tests for ensuring proper configuration of the web
server (e.g. correct web application descriptors and packaging) or
are these tested manually?
I have Deployment Tests, which generally use the Gold Master technique
on deployment descriptors /or/ XMLUnit, to write the descriptors test-first.
Post by Steve Bate
I'm assuming (because of the test execution
speed) that your isolated tests don't access an external database.
True.
Post by Steve Bate
If
you were using an RDBMS, for example, how would you ensure the
application code and database schema are consistent with each other?
Customer Tests generally handle this potential problem. Careful use of
versioning helps. I haven't had a chronic problem in this area, so I'm
not sure how I would solve it.
Post by Steve Bate
We have two categories of tests: unit and functional. The unit tests
are strict isolation tests. The functional tests include both customer
acceptance tests and programmer-originated integration tests for
functionality where it's difficult or impossible to do isolated testing.
I'm sure I do that, too, but I write very few functional tests, and I
often replace them with the corresponding unit tests, over time.
Post by Steve Bate
The fast unit tests meet most of our testing needs while the much slower
functional tests fill the need for integration testing (usually with
external, third party systems like messaging middleware and databases).
How do you do the latter types of testing?
I write some Learning Tests to understand how to use the corresponding
APIs, then use that knowledge to write interaction-based mock object
tests for my application objects. I usually don't run the Learning Tests
regularly, because they test third-party software, and not mine; so I
run them as part of a continuous build, but not as part of the tests I
need for refactoring or check-in.
Post by Steve Bate
You mentioned that you have been using your techniques with a very
small team and wasn't sure how it would scale. Our team has been using
the strict mock-based unit testing for several years now with a team
whose size has ranged from 5 to 20 developers and we've had excellent
results.
Oh, I feel confident it would scale, but I don't have much experience
actually doing it. It's good to read a success story in that direction.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-07-31 15:26:56 UTC
Permalink
[...] I may have a Repository interface. When I implement
this completely in memory, for testing purposes, this is
not a fake, and not a mock, but rather, an alternate
implementation. It is a full-bore in-memory Repository,
and it would be production worthy if it weren't for this
story here that says, "I want to be able search among
all the forms ever submitted in the system," which seems
to imply a certain kind of persistence. :)
You can read a story about how I did this in the past--
about 2001 while at IBM--in Better Software Magazine's
April 2004 edition. I first used an in-memory Repository
(though I didn't call it that then) to drive the design
of the object model, then a few weeks before release,
implemented the RDBMS implementation to talk to our
master database. Only then did I create the database
schema to support it. It worked quite well for me.
Well, ditch the database, and just take one simple step to full blown
Object Prevalence technology, possibly with Prevayler. ;-> About
all you need to add is Command objects.

http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-31 16:17:57 UTC
Permalink
Post by Jeff Grigg
Well, ditch the database, and just take one simple step to full blown
Object Prevalence technology, possibly with Prevayler. ;-> About
all you need to add is Command objects.
A few months ago we experimented with Prevayler as a way to improve
the performance of our transaction processing application and we
decided not to use it. We experimented with it in two areas of
functionality. The first one was transaction intensive. We saw
no significant speed increase using Prevayler over Oracle which
is consistent with the benchmarks on their web site (MySql is
about 3x the performance of both Prevayler while other benchmarks
have shown that MySQL is also about 3x faster than Oracle). Although
the Prevayler implementation is obviously much simpler than an RDBMS,
/using it/ isn't necessarily simpler. We concluded that implementing our
own transactions (especially the manual implementation of rollbacks)
made Prevayler usage more complex than our current usage of O/R mapping
with Oracle. We were also concerned about losing the support for schema
evolution, ad hoc query and inspection of our data, and other
capabilities.

The other area of functionality did not require transactions and involved
a relatively small and simple set of data. We decided to use a random
access file and achieved a dramatic performance increase over Prevaylor
or an RDBMS solution. As a side note, we made a very small change
(a trivial memory cache) to the Prevayler scalability benchmark and
achieved about 80% of the Prevayler performance with Oracle. This was
using the read-only benchmark that they use to claim the almost 10000x
performance improvement over Oracle. I think Object Prevalence is an
interesting idea, but some of the claims seem to be a bit overstated
based on my experience.

Steve



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William Pietri
2004-08-01 20:23:28 UTC
Permalink
Post by Steve Bate
The other area of functionality did not require transactions and involved
a relatively small and simple set of data. We decided to use a random
access file and achieved a dramatic performance increase over Prevaylor
or an RDBMS solution.
I'm a little puzzled by this. Could you tell us more? Prevayler reads
are all in RAM with no context switch, whereas reading the file would
seem to require using the OS to do I/O. Prevayler writes just append to
an existing file, whereas file reads involve seeks. How did your
solution work? And do you have theories on where the performance
increase came from?

Thanks,

William



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-08-01 21:26:00 UTC
Permalink
Post by William Pietri
Post by Steve Bate
The other area of functionality did not require transactions and involved
a relatively small and simple set of data. We decided to use a random
access file and achieved a dramatic performance increase over Prevaylor
or an RDBMS solution.
I'm a little puzzled by this. Could you tell us more? Prevayler reads
are all in RAM with no context switch, whereas reading the file would
seem to require using the OS to do I/O. Prevayler writes just append to
an existing file, whereas file reads involve seeks. How did your
solution work? And do you have theories on where the performance
increase came from?
Hi William,

There are several potential reasons for the performance increase. We
maintained a simple write-though cache of the data so read performance
would be similar to a Prevayler aproach. The write performance was more
of an issue. Appending to a file is not necessarily a fast operation
relative to random access in a small file. Both require a disk seek
but a file append operation generally must update more persistent data
structures (e.g. a file allocation table in Windows, inode list in
Unix/Linux) which might require multiple disk seeks. We didn't need
to store transactions so the file append was unnecessary in this case.

I'm actually puzzled why MySQL is 3x faster than Prevayler in their
transaction processing benchmark. I can believe that a network write
with a fast network and controller would be faster than a disk write
but it seems MySQL would have to write the data to it's transaction
log before acknowledging the transaction commit. I'm curious
how the network write plus the disk write is faster than just the
disk write. We definitely saw similar results when we ran
the benchmarks. Any ideas? Java serialization overhead in Prevayler
might be a candidate hypothesis.

Hmmm, we're kinda drifting off the topic of this thread aren't we?
If I didn't mention if before, we do conventional mocking of our
repositories for unit test purposes.

Steve



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-08-01 22:02:02 UTC
Permalink
Post by Steve Bate
There are several potential reasons for the performance increase. We
maintained a simple write-though cache of the data so read performance
would be similar to a Prevayler aproach. The write performance was more
of an issue. Appending to a file is not necessarily a fast operation
relative to random access in a small file. Both require a disk seek
but a file append operation generally must update more persistent data
structures (e.g. a file allocation table in Windows, inode list in
Unix/Linux) which might require multiple disk seeks. We didn't need
to store transactions so the file append was unnecessary in this case.
I'm actually puzzled why MySQL is 3x faster than Prevayler in their
transaction processing benchmark. I can believe that a network write
with a fast network and controller would be faster than a disk write
but it seems MySQL would have to write the data to it's transaction
log before acknowledging the transaction commit. I'm curious
how the network write plus the disk write is faster than just the
disk write. We definitely saw similar results when we ran
the benchmarks. Any ideas? Java serialization overhead in Prevayler
might be a candidate hypothesis.
Hmmm, we're kinda drifting off the topic of this thread aren't we?
If I didn't mention if before, we do conventional mocking of our
repositories for unit test purposes.
We might be drifting off, but it's very interesting. I hope that folks with
the right tools will dig into this. On the face of it, it's not clear
what's going on. Most peculiar, mama.

Ron Jeffries
www.XProgramming.com
Bang, bang, Jeffries' silver hammer came down upon their heads ...




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-08-02 03:14:52 UTC
Permalink
Post by Steve Bate
Post by William Pietri
[...] We decided to use a random access file and achieved
a dramatic performance increase over Prevaylor or an RDBMS
solution.
I'm a little puzzled by this. Could you tell us more?
[...] And do you have theories on where the performance
increase came from?
There are several potential reasons for the performance
increase. [...]
I wonder if Prevayler is flushing too much. Flush tends to be an
expensive operation. Maybe Prevayler needs to be tuned to flush
command serialization to disk less often.

Efficiency of Java serialization could also be an issue. I've been
reading about "Berkeley DB Java Edition" recently, and they provide
an alternate serialization mechanism, to avoid Java's inefficiencies.

Berkeley DB Java Edition:
http://www.sleepycat.com/products/je.shtml
Post by Steve Bate
[...] Appending to a file is not necessarily a fast
operation relative to random access in a small file.
Both require a disk seek but a file append operation
generally must update more persistent data structures
([...]) which might require multiple disk seeks. [...]
Maybe Prevayler should preallocate non-trivial blocks of disk space
for its log files to avoid going through disk space allocation so
frequently. (And grow them in block sizes too.)
Post by Steve Bate
I'm actually puzzled why MySQL is 3x faster than
Prevayler in their transaction processing benchmark.
...and that they're not talking about it. It seems like something
they should want to "fix."
Post by Steve Bate
[...] I'm curious how the network write plus the disk
write is faster than just the disk write. We definitely
saw similar results when we ran the benchmarks. Any
ideas? Java serialization overhead in Prevayler
might be a candidate hypothesis.
Me too!

Maybe Prevayler needs some tuning and performance improvements.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
William Pietri
2004-08-02 03:20:11 UTC
Permalink
Post by Steve Bate
Hmmm, we're kinda drifting off the topic of this thread aren't we?
If I didn't mention if before, we do conventional mocking of our
repositories for unit test purposes.
Indeed. It would be great if you could post your experiences, perhaps
just by forwarding your answer to my question, to
prevayler-***@lists.sourceforge.net. I'm sure they'd be
interested to hear the details.

Thanks,

William



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-08-02 16:18:49 UTC
Permalink
Post by Jeff Grigg
[...] I may have a Repository interface. When I implement
this completely in memory, for testing purposes, this is
not a fake, and not a mock, but rather, an alternate
implementation. It is a full-bore in-memory Repository,
and it would be production worthy if it weren't for this
story here that says, "I want to be able search among
all the forms ever submitted in the system," which seems
to imply a certain kind of persistence. :)
You can read a story about how I did this in the past--
about 2001 while at IBM--in Better Software Magazine's
April 2004 edition. I first used an in-memory Repository
(though I didn't call it that then) to drive the design
of the object model, then a few weeks before release,
implemented the RDBMS implementation to talk to our
master database. Only then did I create the database
schema to support it. It worked quite well for me.
Well, ditch the database, and just take one simple step to full blown
Object Prevalence technology, possibly with Prevayler. ;-> About
all you need to add is Command objects.
http://www.prevayler.org/wiki.jsp?topic=PrevalenceSkepticalFAQ
If it weren't for interoperation with other applications that demand
RDBMS... I just haven't had a real project on which I've been allowed to
try Prevayler.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-08-02 17:43:37 UTC
Permalink
Post by J. B. Rainsberger
Post by Jeff Grigg
Well, ditch the database, and just take one simple step
to full blown Object Prevalence technology, possibly
with Prevayler. ;->
If it weren't for interoperation with other applications
that demand RDBMS... I just haven't had a real project
on which I've been allowed to try Prevayler.
That's perverse. Why would sensible people go through all the
trouble of building a proper three tier architecture, to separate
presentation, business logic, and database access implementations
from each other, and then blow it all by letting everyone else access
the physical database schema directly? Is there no sense in the
world? Sensible people would have applications talk to each
other "business layer to business layer" -- service-oriented
architectures.


(And yes, I know all about it; it's something that I see happen *all
the time.* ;-)



(And, well, I haven't been allowed to try Prevayler either. )-:



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kari Hoijarvi
2004-08-02 21:25:19 UTC
Permalink
One valid reason is, that many people want to use many kinds
of analysis tools, that require SQL database access.

After all, relational joins and filters are order of
magnitude easier to write than network traversal code.

Kari

-----Original Message-----
Post by J. B. Rainsberger
If it weren't for interoperation with other applications
that demand RDBMS... I just haven't had a real project
on which I've been allowed to try Prevayler.
That's perverse. Why would sensible people go through all the
trouble of building a proper three tier architecture, to separate
presentation, business logic, and database access implementations
from each other, and then blow it all by letting everyone else access
the physical database schema directly?




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dale Emery
2004-07-31 01:30:52 UTC
Permalink
Hi Ron,
Post by Ron Jeffries
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single object
in complete isolation from the implementation details of its
collaborators--that is, nothin' but interfaces.
I see the value of this. But I have a fear. Do you find that
you get into integration problems very frequently, where two
or more classes are passing their isolated tests but don't
play well together? What's your experience and practice on
that?
J. B.'s goal doesn't preclude testing chunks larger than objects.
I can't tell from his subsequent posts whether he also tests
progressively larger chunks (each in isolation from its
collaborators), but it's certainly possible.

Dale
--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Some people bungee jump; I write. --Barbara Kingsolver



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-31 03:00:54 UTC
Permalink
Post by Dale Emery
Hi Ron,
Post by Ron Jeffries
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single object
in complete isolation from the implementation details of its
collaborators--that is, nothin' but interfaces.
I see the value of this. But I have a fear. Do you find that
you get into integration problems very frequently, where two
or more classes are passing their isolated tests but don't
play well together? What's your experience and practice on
that?
J. B.'s goal doesn't preclude testing chunks larger than objects.
I can't tell from his subsequent posts whether he also tests
progressively larger chunks (each in isolation from its
collaborators), but it's certainly possible.
I don't often, because I don't often find it necessary. I generally
prefer not to--at least not for programmer tests.

But you're right: I don't exclude the possibility.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-08-02 09:00:01 UTC
Permalink
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single
object in complete isolation from the implementation
details of its collaborators--that is, nothin' but
interfaces. The result of achieving 95%+ of this goal
is 100 tests per second, or 60,000 tests in 10
minutes.
I appreciate the importance of executing full unit
tests in a very short time.

However, TDD is also a design technique. I have
observed that mocking or stubbing make it possible to
unit test fragile, rigid, highly coupled designs. I
feel therefore that unit testing without mocks or stubs
has a more positive influence on the design. This is
important when working with teams in which everyone may
not be a long-seasoned OO programmer.

Another concern I have with respect to your approach is
that although the application's classes have been
decoupled, the unit tests have become coupled with the
code's implementation.

An important aim of object-oriented design is hiding
the implementation details. I have found TDD to be very
useful in helping programmers think about objects from
an external, client perspective. Tests coded this way
are independent of the implementation of the object
under test. Stubbing or mocking the collaborators of
the object under test makes the tests dependent on that
implementation. On long-running projects, I have
observed that this has two drawbacks:

1) the code/test base is less flexible: each change
requires more work.
2) refactoring is less safe: it is almost always
necessary to change both code and unit tests at the
same time.

The approach I favour is therefore only to stub
external, performance-unfriendly things such as
databases and filesystems. Sure, every now and then, it
becomes necessary to optimise the unit test run. I view
this as a good thing: it usually leads to removing
duplication in the tests, which makes them more
readable and maintainable, and optimising the code
itself, which then benefits the application.

Regards,

Dominic Williams
http://www.dominicwilliams.net

For a software-patent-free Europe:
http://www.noepatents.org

----



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-08-02 09:30:08 UTC
Permalink
Post by Dominic Williams
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single
object in complete isolation from the implementation
details of its collaborators--that is, nothin' but
interfaces. The result of achieving 95%+ of this goal
is 100 tests per second, or 60,000 tests in 10
minutes.
I appreciate the importance of executing full unit
tests in a very short time.
However, TDD is also a design technique. I have
observed that mocking or stubbing make it possible to
unit test fragile, rigid, highly coupled designs. I
feel therefore that unit testing without mocks or stubs
has a more positive influence on the design. This is
important when working with teams in which everyone may
not be a long-seasoned OO programmer.
I'm not seeing why this might be true. (I do have my own fear that without
integrating the code it won't work, but that seems to me to be a separate
issue.)

Could you say more about how mocks and stubs interfere with the design?
Post by Dominic Williams
Another concern I have with respect to your approach is
that although the application's classes have been
decoupled, the unit tests have become coupled with the
code's implementation.
In what way are they more coupled than usual? Let me see if I can guess.
Hmm ...

If a class A is tested in situ, using its real collaborators B and C, the
tests for A only talk to A and know about A. (There are quite likely tests
for B and C somewhere else.)

If we test with mocks as JB describes, then A's tests will include
references to (or implementations of) BMock and CMock.

When the design of A changes, It may no longer need B and C, but D and E
instead. If this happens, the tests have to change to create and use DMock
and EMock.

Is that the concern? It seems credible. JB, does that happen to you? If so,
doesn't it bother you? If not, why not? I can imagine one reason, as long
as I'm in speculation mode:

Working as JB does, you wind up writing mocks or stubs for every class.
Therefore if A's design does change, the changes to use different mocks or
stubs might be pretty simple. I can imagine this happening, but my
experience suggests that mocks and stubs are pretty specific to their
usage, and can also imagine that the ones already built wouldn't be useful
in the new situation.

JB?
Post by Dominic Williams
An important aim of object-oriented design is hiding
the implementation details. I have found TDD to be very
useful in helping programmers think about objects from
an external, client perspective. Tests coded this way
are independent of the implementation of the object
under test. Stubbing or mocking the collaborators of
the object under test makes the tests dependent on that
implementation. On long-running projects, I have
1) the code/test base is less flexible: each change
requires more work.
2) refactoring is less safe: it is almost always
necessary to change both code and unit tests at the
same time.
In my own work, I move around in the space of options and try to figure out
what's best, but I do that on a very intuitive basis: "Ow! I won't do
/that/ again!", "Mmm, that was nice!"

Tell us in a bit more depth, if you can, about your observations. I'm
interested in comparisons, things that happened affecting both 1 and 2
above.
Post by Dominic Williams
The approach I favour is therefore only to stub
external, performance-unfriendly things such as
databases and filesystems. Sure, every now and then, it
becomes necessary to optimise the unit test run. I view
this as a good thing: it usually leads to removing
duplication in the tests, which makes them more
readable and maintainable, and optimising the code
itself, which then benefits the application.
That has been my practice as well. In fact I stub and mock very rarely. On
the other hand, my own programs are small one- or two-person projects. And
I agree that there are plenty of ways to keep the tests fast: the main
question is whether one values test speed enough to give it attention, I
think.

JB? What are your reactions?

Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide whether it's true for you.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-08-02 13:31:47 UTC
Permalink
Post by Ron Jeffries
I'm not seeing why this might be true.
See below.
Post by Ron Jeffries
(I do have my own fear that without integrating the
code it won't work, but that seems to me to be a
separate issue.)
Yes, I share that fear, because I have seen it borne
out in practice, but it has not been such a big issue
as the other ones.
Post by Ron Jeffries
Could you say more about how mocks and stubs
interfere with the design?
I didn't really say they /interfered/. They won't
prevent a good designer from doing his stuff.

Mocks and stubs are staple diet for people working on
legacy code. Why? Because they make it possible to add
unit tests to a bad, highly coupled design.

So what I actually said is that, on a team where
everyone doesn't spontaneously produce high cohesion
and low coupling, working without mocks is more likely
to encourage these caracteristics in the design.
Post by Ron Jeffries
If a class A is tested in situ, using its real
collaborators B and C, the tests for A only talk to A
and know about A. (There are quite likely tests for B
and C somewhere else.)
If we test with mocks as JB describes, then A's tests
will include references to (or implementations of)
BMock and CMock.
When the design of A changes, It may no longer need B
and C, but D and E instead. If this happens, the
tests have to change to create and use DMock and
EMock.
Is that the concern?
Precisely. It doesn't even take such a drastic change
in A's design for the tests or their mocks (which are
often specific to a test, not to mention the case where
self-shunt is being used) to need to be changed: just
changing the way B and C are being used, or the moment
when they are called (e.g. at construction or on demand)
could be enough.

Regards,

Dominic Williams
http://www.dominicwilliams.net

For a software-patent-free Europe:
http://www.noepatents.org

----



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-08-02 17:52:23 UTC
Permalink
Post by Dominic Williams
Post by Ron Jeffries
If a class A is tested in situ, using its real
collaborators B and C, the tests for A only talk to A
and know about A. (There are quite likely tests for B
and C somewhere else.)
If we test with mocks as JB describes, then A's tests
will include references to (or implementations of)
BMock and CMock.
When the design of A changes, It may no longer need B
and C, but D and E instead. If this happens, the
tests have to change to create and use DMock and
EMock.
Is that the concern?
Precisely. It doesn't even take such a drastic change
in A's design for the tests or their mocks (which are
often specific to a test, not to mention the case where
self-shunt is being used) to need to be changed: just
changing the way B and C are being used, or the moment
when they are called (e.g. at construction or on demand)
could be enough.
Understood. It occurs to me now that this is one of those things I'd expect
a team to find its own balance on, and that biasing them at all might be
unnecessary or even unwise. Could that be the case?

Ron Jeffries
www.XProgramming.com
You are closing your eyes to a situation you do not wish to acknowledge.
--Professor Harold Hill




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-08-02 22:13:48 UTC
Permalink
Post by Ron Jeffries
Understood. It occurs to me now that this is one of those things I'd expect
a team to find its own balance on, and that biasing them at all might be
unnecessary or even unwise. Could that be the case?
A wise remark, as usual, but:

1) the teams I have known do like to get a bit of guidance
2) I was trying to compensate for any bias that might have arisen from
JB's suggestion, so that folks do try it both ways.

Cheers,

Dominic Williams
http://www.dominicwilliams.net
----



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-08-02 13:44:00 UTC
Permalink
Post by Ron Jeffries
...
Working as JB does, you wind up writing mocks or stubs for every class.
Therefore if A's design does change, the changes to use different mocks or
stubs might be pretty simple. I can imagine this happening, but my
experience suggests that mocks and stubs are pretty specific to their
usage, and can also imagine that the ones already built wouldn't be useful
in the new situation.
Early in the project we manually wrote mock classes. These were reusable
in different situations. Now we use a reflection-based mock implementation
that eliminates the need to manually write the mock class implementations.
They are defined, on the fly, based on the interfaces and expected
interactions.
Post by Ron Jeffries
...
That has been my practice as well. In fact I stub and mock very rarely. On
the other hand, my own programs are small one- or two-person projects. And
I agree that there are plenty of ways to keep the tests fast: the main
question is whether one values test speed enough to give it attention, I
think.
We rarely seldom give unit test speed much attention. Given the test coding
guidelines we set up at the start of the project, which have benefits beyond
test performance, fast execution is a natural side effect. During the last
few years I can't remember spending any significant time thinking about how
to optimize unit test speed. On the other hand, the functional tests (no mocks,
some stubs/simulators) have required significant effort and a relatively complex
test infrastructure to keep them running reasonably fast.

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-08-02 16:43:50 UTC
Permalink
Post by Ron Jeffries
Ron Jeffries
Post by Dominic Williams
Dominic Williams
Post by J. B. Rainsberger
J. B. Rainsberger
<snip />
Post by Ron Jeffries
When the design of A changes, It may no longer need B and C, but D and E
instead. If this happens, the tests have to change to create and use DMock
and EMock.
Is that the concern? It seems credible. JB, does that happen to you? If so,
doesn't it bother you? If not, why not?
No, it doesn't bother me much, and I can't say why. Maybe the problems
I'm solving at that simple.

<snip />
Post by Ron Jeffries
Working as JB does, you wind up writing mocks or stubs for every class.
Ah, no; for every /interface/ or /protocol/ (and for some classes).
There are generally fewer of these than classes. I have observed
protocols converging quite quickly to something stable, so that the vast
majority of changes in the system are at the implementation level, so
there's little ripple effect.

<snip />
Post by Ron Jeffries
That has been my practice as well. In fact I stub and mock very rarely. On
the other hand, my own programs are small one- or two-person projects. And
I agree that there are plenty of ways to keep the tests fast: the main
question is whether one values test speed enough to give it attention, I
think.
JB? What are your reactions?
I pushed the whole mock thing to its limit on my last solo project (10
weeks), which tested some of my hypotheses regarding mock-driven design.
I had good results--or at least, my poor results came from other poor
decisions, like rolling my own O/R mapping layer, rather than using
Hibernate--so I'm encouraged to do it again. Perhaps next time I'll pay
more attention to what's going on and write about it.

I'm only about 10 papers behind, so what's another on the stack?
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-08-02 13:30:42 UTC
Permalink
Post by Dominic Williams
However, TDD is also a design technique. I have
observed that mocking or stubbing make it possible to
unit test fragile, rigid, highly coupled designs. I
feel therefore that unit testing without mocks or stubs
has a more positive influence on the design. This is
important when working with teams in which everyone may
not be a long-seasoned OO programmer.
Hi Dominic,

We've had quite different experiences and results. Although
our current team is mostly in the seasoned OO programmer
category, I've seen the same unit test techniques work well
with teams of less experienced or skilled programmers (after
some initial coaching). It's possible that some of the
differences in our results might be due to different
terminology.

You are using the term "stubbing" here in addition to mocking.
How do you define those terms? Our mocks have essentially
no behavior. A mocked method returns exactly what it is
explicitly told to return. They never generate any results.
For our functional tests, we sometimes use what we call
simulators. A simulator does have behavior and might
generate results. For example, our application is an
equities and derivative trading system. The functional tests
use a simulator that mimics the behavior of the external
equity and derivative exchanges.

We have had no problem (that I remember) with increased
coupling due to mock-based unit testing. Given that each
class is dependent only on abstractions (interfaces) has the
opposite effect. Could you give some examples of how mocking
leads to highly coupled designs?
Post by Dominic Williams
Another concern I have with respect to your approach is
that although the application's classes have been
decoupled, the unit tests have become coupled with the
code's implementation.
An important aim of object-oriented design is hiding
the implementation details. I have found TDD to be very
useful in helping programmers think about objects from
an external, client perspective. Tests coded this way
are independent of the implementation of the object
under test. Stubbing or mocking the collaborators of
the object under test makes the tests dependent on that
implementation. On long-running projects, I have
You are correct. A unit test is testing a concrete class
implementation and is exposed to that concrete class's
collaborators. Even so, a unit test can be written from a
black box (vs. white or gray box) perspective so that the
exposure is only to the collaborators and not to other
implementation details. The benefit of using mocks for
the collaborators is that the unit test is only exposed
to the /direct/ collaborators.

Suppose you have a class A that depends on B and C, and B
depends on D and E, and C depends on F and G, and so on. In
a unit test, we'd mock B and C. The test would have to set
up and tear down those two mocks. If we don't use mocks, we
have to set up and tear down B,C,D,E,F,G and all the other
indirect dependencies. The test is not only dependent on
the implementation of the class under test but also on the
implementations of all indirectly dependent classes.

One side effect of mocking is that it's a pain to have too
many direct dependencies from a class. This naturally triggers
us to look for higher level, meaningful abstractions that
simply the design and testing. This is one force that leads
to a Repository abstraction and associated mocks rather than
depending directly on JDBC or file access code. Setting up
the relatively simple mock Repository calls is easy compared
to setting up mock JDBC calls. It's these types of
considerations that make me think that our mock-based testing
leads to a more decoupled design rather than less. Even the
less experienced programmers quickly learn than decoupling
and creating good abstractions will make their testing work
easier.

When doing TDD, I find it valuable to be able to focus on
the class I'm designing and the abstractions it depends upon
rather than having to design the implementation of all
dependent, concrete classes at the same time. Again,
decoupling happens almost automatically in this context
Post by Dominic Williams
1) the code/test base is less flexible: each change
requires more work.
Let's say you have a concrete class X that, indirectly
(possibly through many levels of indirection), is used
by almost every class in the system. The internal
implementation of X is modified in a way that requires it
to be set up slightly differently (e.g., a constructor
argument is added). The setup method for every test case
that tests an object indirectly related to X must now be
modified. If X mocks were used, only the X test case would
be modified. All other tests are not dependent on the
concrete implementation of X. I realize a team could
mitigate this issue by using an "object mother" rather
than mocks. I haven't used that approach so I don't know
how much work is usually involved in modifying the
related object mother methods in a scenario like this one.
Post by Dominic Williams
2) refactoring is less safe: it is almost always
necessary to change both code and unit tests at the
same time.
Again, it depends on the type of refactoring, but I agree
this is often the case. How do you avoid modifying tests
that depend directly and indirectly on refactored concrete
classes?

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-08-02 13:53:26 UTC
Permalink
Post by Steve Bate
You are using the term "stubbing" here in addition to mocking.
How do you define those terms? Our mocks have essentially
no behavior. A mocked method returns exactly what it is
explicitly told to return. They never generate any results.
For our functional tests, we sometimes use what we call
simulators. A simulator does have behavior and might
generate results. For example, our application is an
equities and derivative trading system. The functional tests
use a simulator that mimics the behavior of the external
equity and derivative exchanges.
As I understand the terminology, the word "mock" should be reserved for
objects which, in addition to simulating the real thing for the client
objects, also record information and give it back to the tests.

For example, an object that responds to Open, Read, and Close by
conditioning what Read gets depending on what Open asked for, would be a
stub. If the object also records whether Open, Read, and Close are done in
that order, or which "files" are opened in which order, then that object
would be called a mock.

I could be wrong about the terms, but that's my understanding.

Ron Jeffries
www.XProgramming.com
Do only what is necessary. Keep only what you need.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dominic Williams
2004-08-02 14:41:06 UTC
Permalink
Hi Steve,
Post by Steve Bate
We've had quite different experiences and results.
That's interesting.
Post by Steve Bate
It's possible that some of the differences in our
results might be due to different terminology.
It doesn't sound like it from the rest of your post.
Post by Steve Bate
You are using the term "stubbing" here in addition to
mocking. How do you define those terms?
It sounds as though I use the term "stub" for what you
call a mock. I use the word "mock" for stubs that are
developped using a framework such as mockobjects.com,
or even generated with a tool such as easymock.org. I
think they are interchangeable for the purpose of this
discussion.

I am definitely not using either stub or mock to mean a
simulator.
Post by Steve Bate
Could you give some examples of how mocking leads to
highly coupled designs?
As I already said in my response to Ron, I did not say
that mocking leads to that. I said that mocking allows
it.
Post by Steve Bate
Suppose you have a class A that depends on B and C,
and B depends on D and E, and C depends on F and G,
and so on. In a unit test, we'd mock B and C. The
test would have to set up and tear down those two
mocks. If we don't use mocks, we have to set up and
tear down B,C,D,E,F,G and all the other indirect
dependencies. The test is not only dependent on the
implementation of the class under test but also on
the implementations of all indirectly dependent
classes.
But mocking B and C, while making A's test simpler to
setup, has allowed you to leave all those dependencies
in the actual code...

Not resorting to mocks and /still/ simplifying A's test
forces you to reduce A's dependency on all those other
classes, or just to make A easier to setup.
Post by Steve Bate
One side effect of mocking is that it's a pain to
have too many direct dependencies from a class. This
naturally triggers us to look for higher level,
meaningful abstractions that simply the design and
testing.
Hey, that's what I wanted to say about /not/ mocking!
Then it sounds as though we have two ways of achieving
the same thing!
Post by Steve Bate
This is one force that leads to a Repository
abstraction and associated mocks rather than
depending directly on JDBC or file access code.
Long before mock objects were all the craze they now
are, vanilla XP unit testing had already lead me to
that pattern.
Post by Steve Bate
When doing TDD, I find it valuable to be able to
focus on the class I'm designing and the abstractions
it depends upon rather than having to design the
implementation of all dependent, concrete classes at
the same time.
Are you really doing TDD if to implement a class, you
already need several other classes? Isn't the TDD way
to just make it pass (faking or hard-coding if
necessary), then refactor?

If you are working on a very small story, where does
the need for all these dependent, concrete classes come
from? What's happened to YAGNI? You just put all the
code in one class, for starters. Breaking it down into
several classes comes from doing subsequent stories.
Post by Steve Bate
Let's say you have a concrete class X that,
indirectly (possibly through many levels of
indirection), is used by almost every class in the
system. The internal implementation of X is modified
in a way that requires it to be set up slightly
differently (e.g., a constructor argument is
added). The setup method for every test case that
tests an object indirectly related to X must now be
modified.
No, that would only be true if it were necessary to
setup X explicitly in order to be able to setup a class
that uses X even indirectly. This is obviously an
example of duplication, which can and should be
refactored.

Remember that I am not suggesting that it is OK to have
tests or code look the way you say they become without
mocking... I am rather saying that I favour other
solutions.
Post by Steve Bate
Post by Dominic Williams
2) refactoring is less safe: it is almost always
necessary to change both code and unit tests at the
same time.
Again, it depends on the type of refactoring, but I
agree this is often the case. How do you avoid
modifying tests that depend directly and indirectly
on refactored concrete classes?
I can't completely: it's just that in general, only the
test of the class being refactored needs changing. And
in such a case, it's nice to know that the tests of all
the classes that use it are there as a safety net,
because they actually exercise real objects, not
mocks...

Dominic Williams
http://www.dominicwilliams.net

For a software-patent-free Europe:
http://www.noepatents.org

----



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-08-02 15:11:26 UTC
Permalink
Post by Dominic Williams
Post by Steve Bate
You are using the term "stubbing" here in addition to
mocking. How do you define those terms?
It sounds as though I use the term "stub" for what you
call a mock. I use the word "mock" for stubs that are
developped using a framework such as mockobjects.com,
or even generated with a tool such as easymock.org. I
think they are interchangeable for the purpose of this
discussion.
Even some of the mock implementations of mockobjects.com
doesn't fit our definition of a mock because they implement
some simple domain-related behavior in places (and it's
burned us a few times).
Post by Dominic Williams
...
Post by Steve Bate
Could you give some examples of how mocking leads to
highly coupled designs?
As I already said in my response to Ron, I did not say
that mocking leads to that. I said that mocking allows
it.
I believe it's more challenging to create highly coupled
designs when classes interact through abstractions rather
than concrete implementations. Mock-based testing
encourages the former in my experience.
Post by Dominic Williams
...
Post by Steve Bate
This is one force that leads to a Repository
abstraction and associated mocks rather than
depending directly on JDBC or file access code.
Long before mock objects were all the craze they now
are, vanilla XP unit testing had already lead me to
that pattern.
My point was that the mock-based testing is other
force that seems to lead developers (especially less
experienced developers) down this path more quickly.
I wasn't saying that one couldn't discover the Repository
pattern without mocks.
Post by Dominic Williams
Post by Steve Bate
When doing TDD, I find it valuable to be able to
focus on the class I'm designing and the abstractions
it depends upon rather than having to design the
implementation of all dependent, concrete classes at
the same time.
Are you really doing TDD if to implement a class, you
already need several other classes? Isn't the TDD way
to just make it pass (faking or hard-coding if
necessary), then refactor?
If you are working on a very small story, where does
the need for all these dependent, concrete classes come
from? What's happened to YAGNI? You just put all the
code in one class, for starters. Breaking it down into
several classes comes from doing subsequent stories.
After the first story, aren't you always doing subsequent
stories? We are many thousands of stories into development
at this point. Maybe we aren't doing TDD the way everyone
else does, but we tend to start refactoring early on
(during TDD) rather than waiting until we have a big
monolithic class implementation. We definitely try to
avoid reimplementing code that's already implemented in
existing classes when doing TDD.

Well, I have to run off to catch a flight. Thanks for the
discussion.

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-08-02 16:46:59 UTC
Permalink
Post by Dominic Williams
Not resorting to mocks and /still/ simplifying A's test
forces you to reduce A's dependency on all those other
classes, or just to make A easier to setup.
But, of course! I do that, too, because it's just good design. For the
rest, I use mocks. Perhaps I'd given the impression that all
collaboration is tested through mocks. Not so. But the moment I have to
do real work to set up a collaborator for the object under test to be
tested, I do the two step: 1. Extract Interface; 2. Introduce Mock.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Laurent Bossavit
2004-08-02 13:42:47 UTC
Permalink
Ron,
Post by Ron Jeffries
If a class A is tested in situ, using its real collaborators B and C,
the tests for A only talk to A and know about A. (There are quite
likely tests for B and C somewhere else.)
Those collaborators have to come from somewhere, though. Are you
assuming that A is instantiating B and C ?

If A is using instances of B and C that were passed to it, then
doesn't the test have to know about B and C ? In which case the test
will have to change if A is changed to use D and E instead ?

Could with discuss a concrete example in a domain more interesting
than EarlyAlphabet ?

Cheers,

-[Laurent]-
There's no sense in being precise when you don't even know what
you're talking about. -- John von Neumann





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-08-02 17:51:05 UTC
Permalink
Post by Laurent Bossavit
Ron,
Post by Ron Jeffries
If a class A is tested in situ, using its real collaborators B and C,
the tests for A only talk to A and know about A. (There are quite
likely tests for B and C somewhere else.)
Those collaborators have to come from somewhere, though. Are you
assuming that A is instantiating B and C ?
Or that they come from somewhere, yes.
Post by Laurent Bossavit
If A is using instances of B and C that were passed to it, then
doesn't the test have to know about B and C ? In which case the test
will have to change if A is changed to use D and E instead ?
Yes. I'd prefer not to do that and, in general, would not.
Post by Laurent Bossavit
Could with discuss a concrete example in a domain more interesting
than EarlyAlphabet ?
I haven't the time or inclination to create one but I might chat about one
if an interesting one came along ...

Ron Jeffries
www.XProgramming.com
Do, or do not. There is no try. --Yoda




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-08-02 16:37:22 UTC
Permalink
Post by Dominic Williams
Post by J. B. Rainsberger
My #1 testing goal is to be able to test every single
object in complete isolation from the implementation
details of its collaborators--that is, nothin' but
interfaces. The result of achieving 95%+ of this goal
is 100 tests per second, or 60,000 tests in 10
minutes.
I appreciate the importance of executing full unit
tests in a very short time.
However, TDD is also a design technique.
Agreed. That's the reason I said "testing goal". I'm emphasizing that
the approach I described is a testing approach, and not a design
technique. I am aware that there are competing interests here. I'm still
exploring the consequences.
Post by Dominic Williams
I have
observed that mocking or stubbing make it possible to
unit test fragile, rigid, highly coupled designs. I
feel therefore that unit testing without mocks or stubs
has a more positive influence on the design. This is
important when working with teams in which everyone may
not be a long-seasoned OO programmer.
I agree that that's possible. However, like anything else, with
appropriate amounts of practice, one stops writing rigid, highly coupled
designs, often by relying on interfaces and narrow, high-level
protocols, rather than primitive operations.

As you say, practice is the key: the long-seasoned OO programmer has
practised enough to know when the mocking she's doing is moving in the
direction of good OO design, rather than poor OO design.
Post by Dominic Williams
Another concern I have with respect to your approach is
that although the application's classes have been
decoupled, the unit tests have become coupled with the
code's implementation.
I have found, so far, that the time saved has outweighed any additional
work, but that's been largely an intuition, rather than measured, proven
results. It's a question of optimizing a little closer to the "system"
level, than the "local" level (a la _Slack_).

<snip />
Post by Dominic Williams
On long-running projects, I have
1) the code/test base is less flexible: each change
requires more work.
2) refactoring is less safe: it is almost always
necessary to change both code and unit tests at the
same time.
I haven't felt much pain in these directions, so either I'm doing
something neat (and I don't think I am), or I'm not hanging around on
projects long enough (more likely the case). I'll need to get on another
multiple-release project (~1 year) to know more for certain.

Take care.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Edmund Schweppe
2004-08-02 16:56:43 UTC
Permalink
Post by Dominic Williams
However, TDD is also a design technique. I have
observed that mocking or stubbing make it possible to
unit test fragile, rigid, highly coupled designs. I
feel therefore that unit testing without mocks or stubs
has a more positive influence on the design.
[ ... ]
Post by Dominic Williams
Another concern I have with respect to your approach is
that although the application's classes have been
decoupled, the unit tests have become coupled with the
code's implementation.
Interesting. I haven't found myself using mocks that much. OTOH, the
first place I found myself using them was in a situation where the need
for mocks grew out of a refactoring. I had a series of classes that took
XML input and generated Active Server Page output; as the requirements
morphed, I found it harder and harder to keep the classes (and their
tests) readable. When I removed the XML-reading functionality from the
page builders into separate classes, I found it much easier to tell what
was going on. In particular, mocking the (refactored) page-builder
classes dramatically improved the readability of the (refactored)
XML-reader classes' tests.
--
Edmund Schweppe -- ***@ieee.org -- http://schweppe.home.tiac.net
The opinions expressed herein are at best coincidentally related to
those of any past, present or future employer.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Jeff Grigg
2004-07-29 03:03:30 UTC
Permalink
[...] The removal of what appears to be duplication
between two objects may involve running just the tests
for those two objects but some obscure behavior change
may actually be reflected in a third test case that I
wasn't thinking about at the time.
Now your entire test sweet may run in minutes. Ours,
unfortunately, takes half an hour on a good day. [...]
I keep thinking that we need a test runner that observes the
coverage of tests, as they run, sees what files I changed, and runs
first the tests that are most likely to be broken.

Further, I keep thinking it would be nice to integrate with the IDE,
like Eclipse, so that every time I save files, it would compile /and
run the tests./ ...and keep each generation of saves separate, so
that I could keep changing and saving and running tests so that the
multiple versions saved and compiled could be running simultaneously
in the background.

Hmmm...
_ _ _

On the other hand, we could make our tests run faster. Think Mock
Object.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Denis Haskin
2004-07-29 13:15:14 UTC
Permalink
Post by Jeff Grigg
I keep thinking that we need a test runner that observes the
coverage of tests, as they run, sees what files I changed, and runs
first the tests that are most likely to be broken.
Further, I keep thinking it would be nice to integrate with the IDE,
like Eclipse, so that every time I save files, it would compile /and
run the tests./ ...and keep each generation of saves separate, so
that I could keep changing and saving and running tests so that the
multiple versions saved and compiled could be running simultaneously
in the background.
See http://pag.lcs.mit.edu/~saff/continuoustesting.html

"Continuous testing uses excess cycles on a developer's workstation to
continuously run regression tests in the background, providing rapid
feedback about test failures as source code is edited. [...] A
continuous testing plugin for Eclipse is now in public beta."

(standard disclaimer, I haven't used this (yet?) but sounds interesting...)

dwh




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 03:17:46 UTC
Permalink
Just things to think about. Your mileage surely will vary.
Post by Ken Boucher
See, the code base I work with is getting rather large. And one thing
is often related to some other thing. In fact that some other thing
may be miles away. The removal of what appears to be duplication
between two objects may involve running just the tests for those two
objects but some obscure behavior change may actually be reflected in
a third test case that I wasn't thinking about at the time.
If this were to happen to me very often at all, I think I'd conclude that
there was likely a design problem somewhere, or a missing coding standard.
Post by Ken Boucher
Now sure, people may think that 30 minutes for a test suite is too
long, but a couple years of coding by a roomful of people tends to be
a heck of a lot of code to run on the machine you're coding on.
Well, the first XP project team had about a dozen people on it for four
years. Last figures I recall, they had 3000 classes, 30,000 methods,
250,000 lines of Smalltalk code. Their tests, with 30,000 asserts, ran in
ten minutes. Whenever the tests started creeping over ten minutes, Rich
Garzaniti would hammer them back down.

Again, just stuff. YMMV.

Ron Jeffries
www.XProgramming.com
There is no award for "being XP". There is an award for doing the right
combination of practices: success.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 04:31:48 UTC
Permalink
Post by Ron Jeffries
Whenever the tests started creeping over ten minutes, Rich
Garzaniti would hammer them back down.
Unit tests are like refactoring. Sure, I can keep hammering them down
(In fact I do) but at what point in the bowling game refactoring
example did you start thinking "My word, if I was paying these people
would I let them go on like this?" At some point you have to accept
that you have databases, a lot of custom client code, and a barrel of
features and as a result, you've got a lot of tests.

But let's pretend I'm down to 10 minutes. Would you do a extremely
small refactoring change and the run the 10 minute test suite before
doing your next really small refactoring change? What would this do
to your velocity?
Post by Ron Jeffries
If this were to happen to me very often at all, I think I'd
conclude that there was likely a design problem somewhere, or a
missing coding standard.
I'm pretty sure that given the fact that I'm one of the coders
there's a 100% chance there's a design problem somewhere and the
coding standard is messed up. Unfortunately the number of perfect
programmers who don't make mistakes is minimal and they don't want to
move to Omaha. It would also probably help our customer to speak with
one voice if their customers weren't in direct competition with each
other. It's like trying to get smalltalk developers and java
developers to agree on what language is best.

Projects face different issues. Things other projects encounter, I'm
mercifully free of. For example, I'm lucky. I'm not on the team that
has to be HIPAA compliant. Rules people here consider as "good
programming practices that everyone does" could well be illegal in
that chunk of code. I don't know. I hope I never have to find out.

Unfortunately for us, I don't even remember the last time we were
down to 12 programmers. I'm not even sure I could name all the
different projects going on right now and what stage they're all in.

And that's what I'm trying to explain. The rule about small tiny
changes in refactoring between unit tests runs depends on a few
things. It depends on codebase size. It depends on the complexity of
the requirements. It depends on how many other people have realized
that their other project doesn't need to reinvent the wheel because
you have a perfectly good set of wheels that just needs a few extra
holes for the hubs and thanks to collective code ownership they've
done just that without you realizing it.

It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Victor
2004-07-29 08:47:14 UTC
Permalink
Post by Ken Boucher
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
A practical question to ask maybe: How much is left for the project to
grow?
Will it be past the law of diminishing returns into the Babel Tower realm?
If the size will not change much, then the discussion is moot. Otherwise
the whole attitude may need to be reexamined. Eventually, somebody may
decide it's time to pay what good quality programming costs.

Victor

==========================================


----- Original Message -----
From: "Ken Boucher" <***@nozen.com>
To: <***@yahoogroups.com>
Sent: Thursday, July 29, 2004 12:31 AM
Subject: Re: [XP] TDD, XP and debuggers
Post by Ken Boucher
Post by Ron Jeffries
Whenever the tests started creeping over ten minutes, Rich
Garzaniti would hammer them back down.
Unit tests are like refactoring. Sure, I can keep hammering them down
(In fact I do) but at what point in the bowling game refactoring
example did you start thinking "My word, if I was paying these people
would I let them go on like this?" At some point you have to accept
that you have databases, a lot of custom client code, and a barrel of
features and as a result, you've got a lot of tests.
But let's pretend I'm down to 10 minutes. Would you do a extremely
small refactoring change and the run the 10 minute test suite before
doing your next really small refactoring change? What would this do
to your velocity?
Post by Ron Jeffries
If this were to happen to me very often at all, I think I'd
conclude that there was likely a design problem somewhere, or a
missing coding standard.
I'm pretty sure that given the fact that I'm one of the coders
there's a 100% chance there's a design problem somewhere and the
coding standard is messed up. Unfortunately the number of perfect
programmers who don't make mistakes is minimal and they don't want to
move to Omaha. It would also probably help our customer to speak with
one voice if their customers weren't in direct competition with each
other. It's like trying to get smalltalk developers and java
developers to agree on what language is best.
Projects face different issues. Things other projects encounter, I'm
mercifully free of. For example, I'm lucky. I'm not on the team that
has to be HIPAA compliant. Rules people here consider as "good
programming practices that everyone does" could well be illegal in
that chunk of code. I don't know. I hope I never have to find out.
Unfortunately for us, I don't even remember the last time we were
down to 12 programmers. I'm not even sure I could name all the
different projects going on right now and what stage they're all in.
And that's what I'm trying to explain. The rule about small tiny
changes in refactoring between unit tests runs depends on a few
things. It depends on codebase size. It depends on the complexity of
the requirements. It depends on how many other people have realized
that their other project doesn't need to reinvent the wheel because
you have a perfectly good set of wheels that just needs a few extra
holes for the hubs and thanks to collective code ownership they've
done just that without you realizing it.
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 11:31:57 UTC
Permalink
Post by Victor
Post by Ken Boucher
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
If the size will not change much, then the discussion is moot.
Otherwise the whole attitude may need to be reexamined.
Eventually, somebody may decide it's time to pay what good quality
programming costs.
Currently the group with the long test run time is in that state
because it has had success, projects in production, sustained growth,
and growing influence over how a company does buisness by delivering
products to market faster with higher customer satisfaction. Or at
least that's been my impression. Since obviously they've managed this
without what you call "good quality programming", perhaps it's time
you took a good close look at "good quality programming" and decided
if it actually has value in the business world. Because whatever this
group is paying for instead seems to be working quite well, thank you
very much.

Those people on an XP team that has doubled, and then doubled again,
and then doubled again, to the point where it is building completely
products within the same business realm for different customers using
shared technology,feel free to give me a call. Because I am very
rapidly getting the opinion that there are people here who would
rather debate on how to do XP in a classroom enviroment than figure
out what to do with a team that has, unfortunately, succeeded.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-29 12:37:14 UTC
Permalink
Post by Ken Boucher
Currently the group with the long test run time is in that state
because it has had success, projects in production, sustained growth,
and growing influence over how a company does buisness by delivering
products to market faster with higher customer satisfaction. Or at
least that's been my impression. Since obviously they've managed this
without what you call "good quality programming", perhaps it's time
you took a good close look at "good quality programming" and decided
if it actually has value in the business world. Because whatever this
group is paying for instead seems to be working quite well, thank you
very much.
Ken,

I've worked on projects in the past with similar results that did
limited or no unit testing, no pair programming, had an off site
customer, did BDUF, had no shared work area, and so on. Cockburn's
research indicates that almost any process can succeed in the right
context. Still, I've seen benefits from the practices I've mentioned
even if they are not absolutely required in every context. In other
words, I don't see this as an all or nothing issue. Even though our
team writes "good enough" quality software today, I believe we can
learn, improve our skills, write even better software, and become
even more successful.

Sometimes people on this list present (sell) their favorite ideas
and techniques as if they are absolutely required for successful
software development. I try, as much as possible, to overlook the
marketing hype and see if there is anything I can pragmatically
apply to my situation. Of course, there are other times when I
just get annoyed.
Post by Ken Boucher
Those people on an XP team that has doubled, and then doubled again,
and then doubled again, to the point where it is building completely
products within the same business realm for different customers using
shared technology,feel free to give me a call. Because I am very
rapidly getting the opinion that there are people here who would
rather debate on how to do XP in a classroom enviroment than figure
out what to do with a team that has, unfortunately, succeeded.
Our software includes a complex heavyweight GUI, a web-based user
interface, a protocol-level frontend/gateway, a web-based administration
application, and a set of distributed server clusters. The code base
is ~ 300 KSLOC and, being a service bureau, we support many different
customers (businesses) that each require somewhat customized
functionality for their end users. This is an XP project and, as I've
reported here before, our unit test suite runs at ~ 250 tests/second.
We achieved this using some of the techniques Ron mentioned,
specifically test coding guidelines. We haven't had to spend much
dedicated effort to keep the suite running fast. In the rare times
when there is a glitch in test performance (and it's relatively
obvious when they normally run as fast as they do) it's always been
due to a violation of the test coding guidelines and has almost
always been easy to remedy. J.B. Rainsberger has reported that
his unit test suite runs at about 100 tests/second on a real world
project. From his descriptions, it sounds like he is using similar
techniques as us (strict mocking, for example). We also use the
Repository pattern (and mock repositories) like Joshua mentioned.

I don't know if this information is useful or not, but it is based
on actual projects and not on a hypothetical or classroom context.

Regards,

Steve





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 12:54:10 UTC
Permalink
This is an XP project and, as I've reported here before, our unit
test suite runs at ~ 250 tests/second.
The difference, of course, being that you have "good quality
programming". Something our team apparently doesn't have, at least
according to one member of this group. That must be because we don't
seem to be using mock objects or speeding up our test code, something
I could have sworn we were doing until I read this thread since so
many people seem to be telling me we're not doing it without ever
having asked.

I'm glad that you're chunking out 250 tests/second. At that speed,
how much code can you have until it becomes impossible to make the 10
minute mark Ron suggests? At that point will you continue to be
an "XP" team or will you be forced to be something else? Or will you
literally "drop everything", including customer improvements, as
someone else here suggests until you hit that 10 minute mark and what
will that do to your velocity and customer satisfaction?

Will you always be able to keep the tests under 10 minutes and if you
can't what do you do?



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-29 13:44:52 UTC
Permalink
Post by Ken Boucher
This is an XP project and, as I've reported here before, our unit
test suite runs at ~ 250 tests/second.
The difference, of course, being that you have "good quality
programming". Something our team apparently doesn't have, at least
according to one member of this group. That must be because we don't
seem to be using mock objects or speeding up our test code, something
I could have sworn we were doing until I read this thread since so
many people seem to be telling me we're not doing it without ever
having asked.
Sarcasm aside, I want to be clear that I'm not saying anything
about the quality of your team's programming or techniques that
you are using. How extensive is your mock usage and what are you
currently doing to improve test performance?
Post by Ken Boucher
I'm glad that you're chunking out 250 tests/second. At that speed,
how much code can you have until it becomes impossible to make the 10
minute mark Ron suggests?
Are we transitioning back from real world to hypothetical here? :)
My rough calculations indicate ~ 7.5 MSLOC. However, it would take
at least a few years before we wrote that much code (even if it
were likely to ever be needed) and processor speed would increase so
it would probably be approaching 10 MSLOC. Hypothetically. However,
I doubt we would ever let it get anywhere close to that performance.
There's just too many disadvantages to a slow running test suite.
Post by Ken Boucher
At that point will you continue to be an "XP" team or will
you be forced to be something else? Or will you literally
"drop everything", including customer improvements, as
someone else here suggests until you hit that 10 minute mark
and what will that do to your velocity and customer satisfaction?
Again, hypothetically, we'd be doing smaller improvements to
manage test performance long before approaching the 10 minute mark.
And no, we wouldn't advocate dropping everything to work on test
performance. We prefer to never get in that situation where a drastic
action like that would be required.
Post by Ken Boucher
Will you always be able to keep the tests under 10 minutes and if you
can't what do you do?
I believe so. Hypothetically. If you asked me if we'll be able to keep
them running in under a minute I'd be a bit less confident. Somewhere
in 40-60 second range we'll start looking for additional ways to
further improve unit test performance. I don't know how we'd be able
to improve the individual test performance beyond the ~ 250 tests/second
other than faster hardware. Another strategy is to reduce the number
of tests that must be run to ensure that development activities
haven't broken the system. Some of the potential strategies to achieve
this are related to the Bounded Context, Shared Kernel, and Segregated
Core patterns described in Evans' DDD book. We already apply some of these
patterns. For example, the GUI and server code overlap through a Shared
Kernel. The GUI tests + kernel tests can be run independently from the
server code + kernel tests. If someone is working on a task that is
exclusively related to the GUI or server they can confidently run a
subset of the unit tests and know they aren't breaking the rest of the
system. Changes to the shared kernel still require running the entire
test suite.

If and when the unit test suite performance starts approaching the minute
mark we'll be looking into what other partitioning we can do to improve
it. Given the GUI/server segregation, it appears our code base
would have to triple in size (~ 1 MSLOC) before this is an issue for us.

Steve





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 13:54:28 UTC
Permalink
Post by Ken Boucher
This is an XP project and, as I've reported here before, our unit
test suite runs at ~ 250 tests/second.
The difference, of course, being that you have "good quality
programming". Something our team apparently doesn't have, at least
according to one member of this group. That must be because we don't
seem to be using mock objects or speeding up our test code, something
I could have sworn we were doing until I read this thread since so
many people seem to be telling me we're not doing it without ever
having asked.
You did bring the problem up, if I recall, and then pushed back HARD
against suggestions. The fact that some people are jerks does not imply
that they're always wrong.
Post by Ken Boucher
I'm glad that you're chunking out 250 tests/second. At that speed,
how much code can you have until it becomes impossible to make the 10
minute mark Ron suggests?
250/second, 15,000 per minute, 150,000 per ten minutes. At a rough guess
you could have 150,000 methods, 15,000 classes, if the C3 Smalltalk figures
carry through.
Post by Ken Boucher
At that point will you continue to be
an "XP" team or will you be forced to be something else? Or will you
literally "drop everything", including customer improvements, as
someone else here suggests until you hit that 10 minute mark and what
will that do to your velocity and customer satisfaction?
If we "dropped everything" when the tests ran for eleven minutes until they
ran at ten again, what would the real impact be on velocity and customer
satisfaction?
Post by Ken Boucher
Will you always be able to keep the tests under 10 minutes and if you
can't what do you do?
Ten minutes is just somebody's nominal number. It's the oldest number in XP
and probably no longer valid. But let's think about "tests fast enough so
we can comfortably run them whenever we wonder how we're doing, without
losing momentum," or something like that.

I don't know whether it's always possible. I do know what I'd do when I
//gave up// on fast enough: I'd subset the tests and go to some kind of
staged release and staged running.

Then ... defects would occasionally slip out of the first stage into later
stages.

That would slow us down because we'd have to fix those problems after the
code base had changed under us, rather than right away as we can do when
things like TDD work.

Then ... I'd try to improve the subsetting. I'd also try to find common
causes of the problems, and see whether there are other changes to coding
styles and standards, or particular targeted refactorings that would reduce
that kind of leakage. That would probably work and improve things.

Then ... I'd find this approach valuable, and I'd try to convince other
people on this and other projects to consider the same thing.

Then ... they would get angry at the notion that they could improve things,
and they would tell me that the project is going just fine the way it is.

For a while, I wouldn't give up on talking about what I believed in, even
though "things are going fine".

But after a while, everything would be really be just fine, because
everyone would be saying everything is just fine.

Improvement stops when we start believing that ideas about how to improve
are insulting.

Ron Jeffries
www.XProgramming.com
If names and real items do not correspond with each other, there will be fighting.
-- Jing Fa




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 14:04:12 UTC
Permalink
Post by Ron Jeffries
You did bring the problem up, if I recall, and then pushed back HARD
against suggestions. The fact that some people are jerks does not
imply that they're always wrong.
Actually, I described it as a state. Others here decided that it was
a problem and decided to tell me how to fix it. I was describing it
as a state because there was a rule being stated that I don't think
is valid because we seem to have found it less important than we
thought it was.
Post by Ron Jeffries
I don't know whether it's always possible. I do know what I'd do
when I //gave up// on fast enough: I'd subset the tests and go to
some kind of staged release and staged running.
I don't recall //giving up//. I do know that when it comes to
testing, this isn't the group I bring my problems or solutions to. I
haven't done that since the screen acceptance testing fiasco way back
when.
Post by Ron Jeffries
Improvement stops when we start believing that ideas about how to
improve are insulting.
Improvement also stops when people discuss solutions that work and
are told that "We cannot suggest that solution, even though it works,
because it goes against the core teachings". That's why I don't use
this group for a sounding board for testing issues. There are other
places that I prefer to get that sort of feedback from.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 14:33:34 UTC
Permalink
Post by Ken Boucher
Post by Ron Jeffries
You did bring the problem up, if I recall, and then pushed back HARD
against suggestions. The fact that some people are jerks does not
imply that they're always wrong.
Actually, I described it as a state. Others here decided that it was
a problem and decided to tell me how to fix it. I was describing it
as a state because there was a rule being stated that I don't think
is valid because we seem to have found it less important than we
thought it was.
Ah. That wasn't clear. When you said that sometimes your local tests showed
good and that then later things broke, I jumped to the conclusion that that
was a problem. I didn't get that your team didn't want to work on it.

What I got out of the discussion was a lot of ideas for fixing such a
problem, if anyone was in such a state and perceived it as a problem worth
addressing. I understand now that you do not perceive it so.

I also got some very interesting statistics on how fast tests can be.
That's very encouraging to me as I think about larger projects.

I don't understand the strength of your reaction given all this. Given that
your state doesn't reflect a problem worth solving in your situation, one
might expect a comment like: "Well, we're happy with the present balance of
things, but thanks for the ideas. I'll try to remember them in case we ever
need them, but we're fine for now."

If I were a psychologist ... but no. I'm not.
Post by Ken Boucher
Improvement also stops when people discuss solutions that work and
are told that "We cannot suggest that solution, even though it works,
because it goes against the core teachings".
No one said that. People did talk about their strongly-held beliefs and
their most precious practices, which differ from your team's. What is it
about those things that troubles you?
Post by Ken Boucher
That's why I don't use this group for a sounding board for testing
issues.
That's OK. There are a couple of smart people here who are occasionally
worth listening to, but good ideas can come from anywhere.
Post by Ken Boucher
There are other places that I prefer to get that sort of feedback from.
I'm glad you have good places to go for what you need. I'm sorry that this
isn't one of them. I'm always trying to help, and so is everyone else here.
If you find anything useful elsewhere that folks could benefit from here,
I'm sure we'd love to hear about it.

Thanks for helping us see some areas for improvement.

Ron Jeffries
www.XProgramming.com
Adapt, improvise, overcome.
--Gunnery Sergeant Tom Highway (Heartbreak Ridge)




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Victor
2004-07-29 15:57:18 UTC
Permalink
Hi Ken,
Post by Ken Boucher
Because I am very
rapidly getting the opinion that there are people here who would
rather debate on how to do XP in a classroom environment than figure
out what to do with a team that has, unfortunately, succeeded.
The following are your words.
Post by Ken Boucher
I'm pretty sure that given the fact that I'm one of the coders
there's a 100% chance there's a design problem somewhere and the
coding standard is messed up. Unfortunately the number of perfect
programmers who don't make mistakes is minimal and they don't want to
move to Omaha.
You asked a specific question, and you got answers. Taking things
personally does neither help solve your issue nor motivate a productive
brainstorming.

There is a story about some imaginary country where under pressure from the
Department of Taxation they invented a new math. Everybody was happy, and
the customer was elated. The tax collection suddenly was much simpler and
money accumulated in country's coffers.

However, the new math was accurate only up to the millions of dollars. With
inflation, tax collections started reaching the billions. When the new math
reached the billions, signs started to reverse. Suddenly, deficits were
growing and became unwieldy. Eventually, the country went bankrupt.

***

Temporary customer satisfaction is only one of the measurements of success.
What stable organizations want is sustained customer satisfaction. In your
case, you have current customer satisfaction, which is very good. On the
other hand, you are concerned that there may be a design issue that may need
some work. Your awareness is good. So, a couple of relevant questions are:

1. How serious the problem really is? and
2. What do you do about it?

Victor



----- Original Message -----
From: "Ken Boucher" <***@nozen.com>
To: <***@yahoogroups.com>
Sent: Thursday, July 29, 2004 7:31 AM
Subject: Re: [XP] TDD, XP and debuggers
Post by Ken Boucher
Post by Victor
Post by Ken Boucher
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
If the size will not change much, then the discussion is moot.
Otherwise the whole attitude may need to be reexamined.
Eventually, somebody may decide it's time to pay what good quality
programming costs.
Currently the group with the long test run time is in that state
because it has had success, projects in production, sustained growth,
and growing influence over how a company does buisness by delivering
products to market faster with higher customer satisfaction. Or at
least that's been my impression. Since obviously they've managed this
without what you call "good quality programming", perhaps it's time
you took a good close look at "good quality programming" and decided
if it actually has value in the business world. Because whatever this
group is paying for instead seems to be working quite well, thank you
very much.
Those people on an XP team that has doubled, and then doubled again,
and then doubled again, to the point where it is building completely
products within the same business realm for different customers using
shared technology,feel free to give me a call. Because I am very
rapidly getting the opinion that there are people here who would
rather debate on how to do XP in a classroom enviroment than figure
out what to do with a team that has, unfortunately, succeeded.
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 16:29:59 UTC
Permalink
Post by Victor
You asked a specific question, and you got answers. Taking things
personally does neither help solve your issue nor motivate a
productive brainstorming.
I'm sorry. I appear to be having serious mental problems. What
specific question about our Unit Testing did I ask people here to
help me solve? I don't recall asking one and I'm not seeing it when I
look back.

I'm sure it's me, but I'm really confusing myself.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dale Emery
2004-07-29 17:10:31 UTC
Permalink
Hi Ken,
I appear to be having serious mental problems. What specific
question about our Unit Testing did I ask people here to help
me solve? I don't recall asking one and I'm not seeing it when
I look back.
I don't see a question, either. I do see something that I read
Now your entire test sweet may run in minutes. Ours,
unfortunately, takes half an hour on a good day. So, for
obvious reasons, I'm not running the entire test sweet after
only changing a method or two.
I read the word "unfortunately" as suggesting that you don't like
the situation, and I interpreted that as expressing a problem.
Perhaps other people interpreted it similarly. Did you mean it
otherwise?

Though I interpreted this as a description of a problem, I don't
see anything that looks like a request for help.

Dale
--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Acquaintance, n. A person we know well enough to borrow from,
but not well enough to lend to. --Ambrose Bierce


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 17:16:41 UTC
Permalink
Post by Dale Emery
I read the word "unfortunately" as suggesting that you don't like
the situation, and I interpreted that as expressing a problem.
Perhaps other people interpreted it similarly. Did you mean it
otherwise?
Though I interpreted this as a description of a problem, I don't
see anything that looks like a request for help.
And, wisely, you therefore didn't offer any. "Me 'at's off to the Master."

Ron Jeffries
www.XProgramming.com
A man hears what he wants to hear, and disregards the rest. -- Paul Simon




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 17:54:27 UTC
Permalink
Post by Steve Bate
Hi Ken,
I appear to be having serious mental problems. What specific
question about our Unit Testing did I ask people here to help
me solve? I don't recall asking one and I'm not seeing it when
I look back.
I don't see a question, either. I do see something that I read
Now your entire test sweet may run in minutes. Ours,
unfortunately, takes half an hour on a good day. So, for
obvious reasons, I'm not running the entire test sweet after
only changing a method or two.
I read the word "unfortunately" as suggesting that you don't like
the situation, and I interpreted that as expressing a problem.
Perhaps other people interpreted it similarly. Did you mean it
otherwise?
Though I interpreted this as a description of a problem, I don't
see anything that looks like a request for help.
Thank you for saying in a wonderful fashion what I have failed to
say.

To everyone else, my apologies.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Dale Emery
2004-07-29 17:29:27 UTC
Permalink
Hi Ken,
Post by Dale Emery
Though I interpreted this as a description of a problem, I
don't see anything that looks like a request for help.
I want to rephrase that: I don't see a clear, explicit request
for help. When people describe problems on mailing lists, I
often interpret that as a request for help. And I'm often
mistaken when I do that, which I find out only later from the way
the person responds to my attempts to help.

Dale
--
Dale Emery, Consultant
Collaborative Leadership for Software People
Web: http://www.dhemery.com
Weblog: http://www.dhemery.com/cwd

Rudeness is the weak man's imitation of strength. --Eric Hoffer



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
J. B. Rainsberger
2004-07-30 17:49:00 UTC
Permalink
Post by Ken Boucher
Because I am very
rapidly getting the opinion that there are people here who would
rather debate on how to do XP in a classroom enviroment than figure
out what to do with a team that has, unfortunately, succeeded.
Well, you're wrong, there, but I am rapidly getting the opinion that in
spite of repeated attempts to get that point across to you, you have no
interest in hearing it.

You know what? No. That statement is patently unfair and ridiculous.
Withdrawn.
--
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 11:27:32 UTC
Permalink
Post by Ken Boucher
Post by Ron Jeffries
Whenever the tests started creeping over ten minutes, Rich
Garzaniti would hammer them back down.
Unit tests are like refactoring. Sure, I can keep hammering them down
(In fact I do) but at what point in the bowling game refactoring
example did you start thinking "My word, if I was paying these people
would I let them go on like this?" At some point you have to accept
that you have databases, a lot of custom client code, and a barrel of
features and as a result, you've got a lot of tests.
Well, as they say over at Adidas, impossible is nothing. Rich used to come
in at odd times and speed up the tests, and never spent much time on it
because he never let them get way up there. (Others of us would work on it
as well, of course, but he was the force behind test timing.)

Anyway, I'm just saying what happened on the largest, longest-running
Smalltalk XP project I know of. Nothing to do with any other project.
Post by Ken Boucher
But let's pretend I'm down to 10 minutes. Would you do a extremely
small refactoring change and the run the 10 minute test suite before
doing your next really small refactoring change? What would this do
to your velocity?
No, of course not. We would run a subset while we coded. The ten minute
tests were run at integration time, each pair two to four times a day. And
the acceptance tests ran an hour or so in GemStone, and we ran those
overnight, with just a selected smoke-test subset at integration.

We drifted tests back and forth between the various subsets all the time,
because we didn't like it when the short set ran and the long set didn't.
Post by Ken Boucher
Post by Ron Jeffries
If this were to happen to me very often at all, I think I'd
conclude that there was likely a design problem somewhere, or a
missing coding standard.
I'm pretty sure that given the fact that I'm one of the coders
there's a 100% chance there's a design problem somewhere and the
coding standard is messed up. Unfortunately the number of perfect
programmers who don't make mistakes is minimal and they don't want to
move to Omaha.
I've only been doing this programming thing a little while, so I could be
way off base on this next thought. I've never seen a project that was
really held back from improving because their programmers weren't good
enough. I've seen projects skip some improvement because the team said
"Good enough." We have to say "Good enough," many times per day. That's OK.
That's our job.

Given that we're not perfect, sometimes "Good enough" isn't.
Post by Ken Boucher
It would also probably help our customer to speak with
one voice if their customers weren't in direct competition with each
other. It's like trying to get smalltalk developers and java
developers to agree on what language is best.
No one is saying that it's easy. I think we're all saying that a set of
outside eyes looks at things and sees things differently, and sometimes
those eyes are just possibly seeing things clearly. The frog in the pot
thing.

The advice is free. The value is what we do with it.
Post by Ken Boucher
Projects face different issues. Things other projects encounter, I'm
mercifully free of. For example, I'm lucky. I'm not on the team that
has to be HIPAA compliant. Rules people here consider as "good
programming practices that everyone does" could well be illegal in
that chunk of code. I don't know. I hope I never have to find out.
Unfortunately for us, I don't even remember the last time we were
down to 12 programmers. I'm not even sure I could name all the
different projects going on right now and what stage they're all in.
The code and test base for all those programmers, or at least all the
Smalltalk programmers, is one big image?
Post by Ken Boucher
And that's what I'm trying to explain. The rule about small tiny
changes in refactoring between unit tests runs depends on a few
things. It depends on codebase size. It depends on the complexity of
the requirements. It depends on how many other people have realized
that their other project doesn't need to reinvent the wheel because
you have a perfectly good set of wheels that just needs a few extra
holes for the hubs and thanks to collective code ownership they've
done just that without you realizing it.
Yes. What else does it depend on?
Post by Ken Boucher
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
There was and is no blame in anything I said. I described what C3 did and
what I think about code when changes here break things there.

Hamlet: Madame, how like you this play?
Queen: ________________________________

Ron Jeffries
www.XProgramming.com
The practices are not XP. They are a path to XP.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 11:55:56 UTC
Permalink
Post by Ron Jeffries
The code and test base for all those programmers, or at least all
the Smalltalk programmers, is one big image?
Yup. And it keeps me up at night.

Basicly, everyone is building their new products using features of
the old products, which really pays off in the code reuse department.
Now it could be possible for a project to take a snapshop of what
they're currently using at any given point of time and get back down
to something that can be tested in a very short timeframe but...

That means any improvements to the foundation need to be ported if
anyone else wants them. For example two people cooked up a new way
for customers to drill down through their corporate hierarchies. This
created a bit of excitement amoung the people in the customer roles.
Because of the shared codebase, the amount of work to write the new
functionality and then to port it into the other projects as needed
was minimal.

Now let's think about what this means. There's a peice of code that
provides a desired function shared between products. So here's a
reusable screen component being used by different teams with
different looking hierarchies with different data. Chances are it's
being tested in each team's indiviual set of screen tests. So if
someone is refactoring that code they may not know all the tests that
execute it. (And I sometimes wonder if that's a variation of a code
coverage tool that would be worthwhile).

Now say it's discovered that some client has grown enough that the
performance of this functionality is an issue, so a bit of work goes
into speeding it up. Not an uncommon problem with production code.
Once again the shared codebase means that all of the products have
just inherited this improvement at no cost to them. More importantly
they're not ever going to know they need it. The customer won't write
that card because they won't be dissatisfied with the same
performance issue, and that goes a long way towards customer
satisfaction.

Another thing to keep in mind is that projects aren't static in size.
This project shrinks in activity. That one grows. People move around
within the team. But since all the code is in one big image, the
version of FlarbNarg that this group uses is the same version of
FlarbNarg that the person moving just finished working on. It's not
something new. The solid foundation he has is of great value on this
other team because they're building on the exact same solid
foundation.

So there are some big gains in doing this. There's some new
challenges in doing it as well. And if we're lucky, more teams are
going to have to face this choice in the future.

--------------
Post by Ron Jeffries
Post by Ken Boucher
It's a good guideline and a nice rule. But it doesn't always apply
and when it doesn't apply any longer I don't think we should be
blaming the project it doesn't apply to because it's still alive,
well, and active.
There was and is no blame in anything I said. I described what C3
did and what I think about code when changes here break things
there.
Yes. Unfortunately you haven't been the only one to reply. Some of
the things in some of the others still have me livid.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 12:23:44 UTC
Permalink
Post by Ken Boucher
Yup. And it keeps me up at night.
Then don't get too bent if it bothers those of us who are just imagining
it. The imagined monsters are always even worse than the real ones.

Anyway ...
Post by Ken Boucher
Basicly, everyone is building their new products using features of
the old products, which really pays off in the code reuse department.
Now it could be possible for a project to take a snapshop of what
they're currently using at any given point of time and get back down
to something that can be tested in a very short timeframe but...
Yes, that would be bad. I've seen teams try to use a "platform" level set
of packages and then local code. It gets to be a big hassle of another
kind.
Post by Ken Boucher
That means any improvements to the foundation need to be ported if
anyone else wants them. For example two people cooked up a new way
for customers to drill down through their corporate hierarchies. This
created a bit of excitement amoung the people in the customer roles.
Because of the shared codebase, the amount of work to write the new
functionality and then to port it into the other projects as needed
was minimal.
Yes. Reuse at its finest ...
Post by Ken Boucher
Now let's think about what this means. There's a peice of code that
provides a desired function shared between products. So here's a
reusable screen component being used by different teams with
different looking hierarchies with different data. Chances are it's
being tested in each team's indiviual set of screen tests. So if
someone is refactoring that code they may not know all the tests that
execute it. (And I sometimes wonder if that's a variation of a code
coverage tool that would be worthwhile).
Indeed. Are you using a refactoring browser? Are you using the word
"refactoring" to mean something else? True refactoring really can't break
anything, ever, can it?
Post by Ken Boucher
Now say it's discovered that some client has grown enough that the
performance of this functionality is an issue, so a bit of work goes
into speeding it up. Not an uncommon problem with production code.
Once again the shared codebase means that all of the products have
just inherited this improvement at no cost to them. More importantly
they're not ever going to know they need it. The customer won't write
that card because they won't be dissatisfied with the same
performance issue, and that goes a long way towards customer
satisfaction.
Yes, that's certainly good ...
Post by Ken Boucher
Another thing to keep in mind is that projects aren't static in size.
This project shrinks in activity. That one grows. People move around
within the team. But since all the code is in one big image, the
version of FlarbNarg that this group uses is the same version of
FlarbNarg that the person moving just finished working on. It's not
something new. The solid foundation he has is of great value on this
other team because they're building on the exact same solid
foundation.
Yes. Less spin-up. Moving people between projects might even have some
extra synergy, since probably different teams focus on and learn different
things.
Post by Ken Boucher
So there are some big gains in doing this. There's some new
challenges in doing it as well. And if we're lucky, more teams are
going to have to face this choice in the future.
Yes. Thanks for raising the benefits and the challenges and letting us talk
about them and try to contribute.

Ron Jeffries
www.XProgramming.com
The greatest mistake we make is living in constant fear that we will make one.
-- John Maxwell




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 12:38:14 UTC
Permalink
True refactoring really can't break anything, ever, can it?
It shouldn't. Unfortunately, I'm a bit of an idiot at times. What I
think was duplication was often just two extremely similar things.
The duplication was a little more subtle than I was realizing.

You've told a story about when you watched someone completely rewrite
a method to expose the duplication and then remove it. When I
completely rewite a method I have to make sure I put my kevlar shoes
on because I'm completely capable of shooting myself in the foot.





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 13:21:38 UTC
Permalink
Post by Ken Boucher
True refactoring really can't break anything, ever, can it?
It shouldn't. Unfortunately, I'm a bit of an idiot at times. What I
think was duplication was often just two extremely similar things.
The duplication was a little more subtle than I was realizing.
You've told a story about when you watched someone completely rewrite
a method to expose the duplication and then remove it. When I
completely rewite a method I have to make sure I put my kevlar shoes
on because I'm completely capable of shooting myself in the foot.
A lot of that idiot thing is going around. That's why I asked about the
refactoring browser.

I'd hope, when removing that apparent duplication, that the tests I chose
to run against it would be sufficient. When they turned out not to be, as
would surely happen from time to time, there would be an opportunity for
learning.

Since I still screw up so often, I feel pretty confident that I've missed
some of those opportunities.

Ron Jeffries
www.XProgramming.com
Ron Jeffries, speaking for Boskone ... Out.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-29 12:19:27 UTC
Permalink
Post by Ken Boucher
But let's pretend I'm down to 10 minutes. Would you
do a extremely
small refactoring change and the run the 10 minute
test suite before
doing your next really small refactoring change?
What would this do
to your velocity?
Does your editor still work during a test run? Could
you start the next tick of the refactor?

More distressingly, could you start more than one test
run at the same time?


=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 12:32:58 UTC
Permalink
Post by Phlip
Does your editor still work during a test run? Could
you start the next tick of the refactor?
More distressingly, could you start more than one test
run at the same time?
Technically, I could version my changes, port them to a second box,
and go on to work with the versioned code, but even assuming I could
do such a thing on a single box without versioning, it still results
in what is basically a code fork and a lot of forking for a 10 minute
run. Should any test suite fail, everything I've done since then is
tossed since it was based on the assumption that the tests would run.

I'm not sure this buys me enough to be worth the exercise. Is it
really any different from just not running all the tests between
every tiny code change? I seem to be having great success with the
latter despite the fact that everyone seems to be telling me not to
do it. (Kind of like XP, now that I think about it.)

Now if all of this was truly transparent to me, sure, I would do it,
but if it was truly transparent to me I'd remove the run tests button
from the image entirely and simply have it kick off the whole suite
every time I save a method and have it track which versions were
successful and whether or not my test base truly covered the change I
just made.

And if anyone here wants to write that tool, you have my blessings.



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Phlip
2004-07-30 05:05:42 UTC
Permalink
eXtremos, eXtremists, and Agilistas:

Google uses XP.

During the same week Google's founders appeared on
Time Magazine (which I think also uses XP, somewhere),
Google upgraded its skin.

This represents an important Lean Development ideal:
The decision to release an upgrade was entirely a
business decision. Google's workflow, from its
programming pit to our browsers, is as short as a
weekly news magazine's.

Now the question: How much of Google's code is test
infected? Does anyone know if their search engine
itself was been iterating XP-style for enough time to
make a difference?

=====
Phlip
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces



__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
John Brewer
2004-07-30 18:52:42 UTC
Permalink
Post by Phlip
Google uses XP.
I wouldn't say we're use XP just yet, but our group at Google (ads) is
trying hard to transition to it. Currently our biggest obstacles are
a legacy codebase with few tests and a build system from hell.

Our group currently has two week development and release cycles, with
about a week of QA between code freeze and release. We don't
currently do XP-style iteration planning, but it's one of my company
goals for the quarter to get my team to use it.

BTW, if anyone on this list is interested in joining this effort, send
me your resume. If I like what I see, I'll enter your resume directly
into our applicant tracking system, along with my recommendation.
That will give you a significant head start, compared to people whose
resumes come in through our regular "jobs" email address. Note that
in addition to XP/agile skills, you need to be able to meet all the
other requirements for the position:

http://www.google.com/jobs/eng/sw.html#java_apdev
--
John Brewer


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Donald F. McLean
2004-07-30 19:10:28 UTC
Permalink
It's a shame that there aren't any Google locations near me.

Donald
Post by John Brewer
Note that
in addition to XP/agile skills, you need to be able to meet all the
http://www.google.com/jobs/eng/sw.html#java_apdev
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Russell Gold
2004-07-30 00:42:54 UTC
Permalink
Post by Phlip
Between each time you hit the test button, all changes
should be so trivial that you could back them out
manually, _without_ the Undo button.
When I am doing TDD, this is frequently the case. During Refactoring
it is often not so. Some refactorings are inherently too large for me
to remember all of the steps. And since my IDE provides a virtual
configuration system (VCS), I just use it rather than depending on
manual undos. Avoiding Undo buttons, like avoiding debuggers, is just
silly if it helps you get the job done.


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Chris Wheeler
2004-07-29 02:02:51 UTC
Permalink
Post by Phlip
Post by Phlip
hit Undo, not bother to inspect why something
failed.
Post by Phlip
(A few Red Bars in a row should raise that
suspicion...)
If I
red bar while
refactoring I want to know WHY.
Me too. Hopefully my red bar test will tell us what
happened (expected this, actually got this...). Short
TDD cycles are so information rich that my partner and
I are able to quickly say "Right, we forgot to do
this..." or "Of course, we did this instead of
this...". Once in a while, we even end up saying
"That's not how we test that...". So we undo and make
appropriate steps to green.

It's never a conscious "I'm an extreme programmer so I
will not use the debugger". It's more of "I know what
to do because my tests told me what to do". My
debugger is just another tool in my toolbox (pre TDD
and XP, it was my only tool - what's the saying - when
all you have is a hammer, everything looks like a
nail?).

Chris.

=====
---------------------------
C H R I S W H E E L E R
Extreme Programmer & Coach

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steven Gordon
2004-07-27 23:54:03 UTC
Permalink
The article even identifies the root cause of the problem:

Programmers "are completely isolated from the people they
are trying to serve and, of course, they are colored by
what they know and what they like," said Margaret Burnett,
a computer science professor at Oregon State University
and director of EUSES.

But, instead of addressing why we cannot develop software in
a way that does not isolate programmers from users and
delivers feedback on what is important to the users early and
often, these people just throw more technology at their own
view of the symptoms of the problem.

Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271

-----Original Message-----
From: Jeff Grigg [mailto:***@charter.net]
Sent: Tuesday, July 27, 2004 4:37 PM
To: ***@yahoogroups.com
Subject: [XP] Re: Carnegie Mellon to the rescue... (or TDD, or existing
tools!!!)
Post by Phlip
http://www.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html
This is so amazing. It reminds me of psychiatrists who
neglect the study of happy & well-adjusted people.
And,
"Adding Whyline to a different language, like Java, which is 10
times as complex, could limit how much Whyline can help."

Great. Lotta' help that is!

And Test Driven Development (TDD), properly followed, dramatically
reduces the problem.

_ _ _


I understand that XP shops don't have that much of a need for
debuggers, but I'm still in the dark ages, ;-> and I was really
impressed by Retro Vue, a "logging debugger" I saw at JavaOne:

http://www.visicomp.com

Essentially, it single-steps through your program as it runs, and
logs everything that happens. This takes a lot of disk space, but
you can scroll forward and backward through "time," to see and query
on anything that happened during the run. Like, "What were all the
previous values of this variable, and where and when were they set?"

Most interesting. I can think of several times I could really have
used it.

(I'm not associated with them in any way. I just found their
product cool.)





To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
y***@jhrothjr.com
2004-07-28 00:57:36 UTC
Permalink
From: "Steven Gordon" <***@yahoogroups.at.jhrothjr.com>
Sent: Tuesday, July 27, 2004 7:54 PM
Subject: RE: [XP] Re: Carnegie Mellon to the rescue... (or TDD, or existing
tools!!!)
Post by Steven Gordon
Programmers "are completely isolated from the people they
are trying to serve and, of course, they are colored by
what they know and what they like," said Margaret Burnett,
a computer science professor at Oregon State University
and director of EUSES.
But, instead of addressing why we cannot develop software in
a way that does not isolate programmers from users and
delivers feedback on what is important to the users early and
often, these people just throw more technology at their own
view of the symptoms of the problem.
Remember that CMU is host to the SEI, those nice
folks that brought us the CMM, CMMi, PSP and TSP.

John Roth
Post by Steven Gordon
Steven A. Gordon, Ph.D.
Manager, Software Factory
Arizona State University
PO Box 875506
Tempe, AZ 85287-9509
http://sf.asu.edu
(480)-727-6271
-----Original Message-----
Sent: Tuesday, July 27, 2004 4:37 PM
Subject: [XP] Re: Carnegie Mellon to the rescue... (or TDD, or existing
tools!!!)
Post by Phlip
http://www.cnn.com/2004/TECH/ptech/07/27/debugging.ap/index.html
This is so amazing. It reminds me of psychiatrists who
neglect the study of happy & well-adjusted people.
And,
"Adding Whyline to a different language, like Java, which is 10
times as complex, could limit how much Whyline can help."
Great. Lotta' help that is!
And Test Driven Development (TDD), properly followed, dramatically
reduces the problem.
_ _ _
I understand that XP shops don't have that much of a need for
debuggers, but I'm still in the dark ages, ;-> and I was really
http://www.visicomp.com
Essentially, it single-steps through your program as it runs, and
logs everything that happens. This takes a lot of disk space, but
you can scroll forward and backward through "time," to see and query
on anything that happened during the run. Like, "What were all the
previous values of this variable, and where and when were they set?"
Most interesting. I can think of several times I could really have
used it.
(I'm not associated with them in any way. I just found their
product cool.)
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ken Boucher
2004-07-29 14:59:48 UTC
Permalink
Post by Ken Boucher
Improvement also stops when people discuss solutions that work and
are told that "We cannot suggest that solution, even though it
works, because it goes against the core teachings".
No one said that.
Actually, in the forum, when it comes to testing, people have. It
changed my opinion about this forum then and nothing I've seen since
then has given me a reason to change back.
People did talk about their strongly-held beliefs and their most
precious practices, which differ from your team's. What is it
about those things that troubles you?
There are a few common attitudes in this group that combined, make my
blood boil.
1) If a group is sucessful XP gets the credit, regardless of what the
group ends up doing.
2) If you're not sucessful it's because you failed to adopt XP. (This
is combined with what sometimes appears to be a complete refusal to
attempt to make XP easier to adopt.) In short, if you fail, XP is not
to blame.
3) If you are sucessful and somehow you're not doing XP, well, even
pigs fly when conditions are right. (see
http://groups.yahoo.com/group/extremeprogramming/message/94787 for
an example of what I mean by this.)

These combined, make me serious fear for the future of what I
consider a good way of learning to write software. It brings forth
the worst in dogmatism and religion.

I'm sorry Ron. You ask questions. You want to talk. I value this
greatly about you. It's probably the only reason I continue to come
here. You offer what you think are possible solutions when I ask for
them and offer questions that lead me to rethink things when I need
that. I find both of these things valuable. And I am desperately
trying to learn exactly how you do it so well because I consider that
one ability more valuable than all the other advice and experience
you have combined.

If I could learn how to do what you do, I could probably turn this
experience around into something positive, but what I keep hearing
from some other members of this forum is "You're doing this wrong
and unless you do things the way I tell you you'll never be a
success." Which in the light of my current experiences makes me
wonder just what the heck the person telling me that is talking about.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-29 15:48:08 UTC
Permalink
Post by Ken Boucher
...
3) If you are sucessful and somehow you're not doing XP, well, even
pigs fly when conditions are right. (see
http://groups.yahoo.com/group/extremeprogramming/message/94787 for
an example of what I mean by this.)
These combined, make me serious fear for the future of what I
consider a good way of learning to write software. It brings forth
the worst in dogmatism and religion.
Hi Ken,

My comments and reference to Cockburn's research were intended to
represent a softer view of what it takes for a software team to be
successful -- context (personality, skills, communication, type of
project, ...) can be more important than the specific processes or
coding techniques being used. More information on Cockburn's
research findings on this topic are at http://tinyurl.com/6koo6 and
elsewhere.

I also never said that your team was not doing XP. I'm not even
interested in that question. What I said is that I've succeeded
on both XP and non-XP projects, that it's often very sufficient
to be good enough (XP or not), and that I also value continuous
improvement since good enough today may not be good enough
tomorrow.

Regards,

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 17:41:33 UTC
Permalink
Post by Ken Boucher
If I could learn how to do what you do, I could probably turn this
experience around into something positive,
If I could learn how I occasionally manage to do what I do, I could
probably turn my life around into something positive.
Post by Ken Boucher
but what I keep hearing
from some other members of this forum is "You're doing this wrong
and unless you do things the way I tell you you'll never be a
success."
I'm really looking hard, and I don't hear them saying that. Of course the
voices in my head are so loud that they may be drowning out the people who
are saying that, but honestly I'm not seeing where that's being said, and
particularly not in the message you pointed to.
Post by Ken Boucher
Which in the light of my current experiences makes me
wonder just what the heck the person telling me that is talking about.
Things they believe in and care about very deeply. Things they fear and
care about very deeply. Passion is scary, even to the reader, especially if
we're working in the same kind of medium.

Through great good chance, I ran across my copy of "Art and Fear"
yesterday, and I took it to lunch to calm myself down after this morning's
frustrating events. I'm glad I did. Two thoughts from the part I read:

Making art now means working in the face of uncertainty, it means living
with doubt and contradiction, doing something no one much cares whether
you do, and for which there may be neither audience nor reward. Making the
work you want to make means setting aside these doubts so that you may
see clearly what you have done, and thereby see where to go next. Making
the work you want to make means finding nourishment within the work
itself. This is not the Age of Faith, Truth, and Certainty.

And:

... we'll side with Conrad's view of fatalism: namely, that it is a
species of fear -- the fear that your fate /is/ in your own hands, but
that your hands are weak.

No, actually, a third thing, think of it as a bonus:

Clearly something's come unbalanced here. After all, if there were some
ongoing redefinition of "what chess is", you'd probably feel a little
uneasy trying to play chess. Of course you could always stick with the
game by limiting yourself to a few easy moves you've seen work for
others. Then again you might conclude that since you weren't sure
yourself what chess was, you weren't a /real/ chess player and were only
faking it when you moved the pieces around. You might secretly come to
believe that you deserve to lose. In fact, you might even quit playing
entirely. If the preceding scenario sounds farfetched vis-a-vis chess, it
remains discouragingly common vis-a-vis art.

And XP. No one knows what XP is, yet we're all trying to do it. It can be
of great value to look at someone else's XP. It doesn't damage or diminish
our own.

Ron Jeffries
www.XProgramming.com
Will Turner: In a fair fight I'd kill you.
Jack Sparrow: That's not much incentive for me to fight fair, then, is it?




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Steve Bate
2004-07-29 18:32:47 UTC
Permalink
Post by Ron Jeffries
...
Through great good chance, I ran across my copy of "Art and Fear"
yesterday, and I took it to lunch to calm myself down after this morning's
Thanks for sharing those passages. I looked on Amazon and there are two
"Art and Fear" books from different authors. Which one was this? I may
pick up a copy. The feeling behind the words reminded me of Richard
Gabriel's writings about duende and the fear of failure.

"Duende, poetry, and perhaps life itself and life in our works of
artifice are denizens of the boundary between order and chaos.
When we look too deeply into chaos for inspiration, we find only
nonsense; when we look too deeply into order for completion and
closure, we find only the botfly of boredom and the disease he
carries: failure and deathlike morphology."
- Richard Gabriel, "Mob Software: The Erotic Life of Code"

Thanks again,

Steve




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Ron Jeffries
2004-07-29 18:37:30 UTC
Permalink
Post by Steve Bate
Thanks for sharing those passages. I looked on Amazon and there are two
"Art and Fear" books from different authors. Which one was this? I may
pick up a copy. The feeling behind the words reminded me of Richard
Gabriel's writings about duende and the fear of failure.
Bayles and Orland.

And if you haven't read Gabriel's book on Writer's Workshops, by all means
do!
Post by Steve Bate
"Duende, poetry, and perhaps life itself and life in our works of
artifice are denizens of the boundary between order and chaos.
When we look too deeply into chaos for inspiration, we find only
nonsense; when we look too deeply into order for completion and
closure, we find only the botfly of boredom and the disease he
carries: failure and deathlike morphology."
- Richard Gabriel, "Mob Software: The Erotic Life of Code"
Dick is always so cheerful ... :)

Ron Jeffries
www.XProgramming.com
You don't want to sell me waterfall.
You want to go home and rethink your life.




To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Kari Hoijarvi
2004-08-02 20:47:51 UTC
Permalink
While I agree with the general consensus of this thread, I'd like to mention, that finding bugs is not the only use of debuggers.

Since I'm a solo developer, pairing is kind of difficult. So I review my code. But I have two problems doing reviews with
incremental development.

One is, that many changes tend to sweep thru multiple files. Fortunately windiff can be used with TortoiseCSV, making it easy to see
what I have actually changed.

The second, and more difficult problem is the fact, that the same person is doing both writing and reviewing. The same person sees
things from the same point of view.

Tomorrow I'm a different person, and I find more problems if I review tomorrow. Unfortunately, this is difficult to do in
incremental development.

My solution is to use the debugger for the first run. Inspecting every changed line while the program is actually running is simply
a better way to review.

Kari



To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Randy MacDonald
2004-08-02 21:25:56 UTC
Permalink
Whatever debuggers give you at human speed, TDD gives you at processor
speed. Computer-based assertions trump human-based inspections.


----- Original Message -----
From: "Kari Hoijarvi" <***@me.wustl.edu>
To: <***@yahoogroups.com>
Sent: Monday, August 02, 2004 4:47 PM
Subject: RE: [XP] Re: TDD, XP and debuggers
Post by Kari Hoijarvi
While I agree with the general consensus of this thread, I'd like to
mention, that finding bugs is not the only use of debuggers.
Post by Kari Hoijarvi
Since I'm a solo developer, pairing is kind of difficult. So I review my
code. But I have two problems doing reviews with
Post by Kari Hoijarvi
incremental development.
One is, that many changes tend to sweep thru multiple files. Fortunately
windiff can be used with TortoiseCSV, making it easy to see
Post by Kari Hoijarvi
what I have actually changed.
The second, and more difficult problem is the fact, that the same person
is doing both writing and reviewing. The same person sees
Post by Kari Hoijarvi
things from the same point of view.
Tomorrow I'm a different person, and I find more problems if I review
tomorrow. Unfortunately, this is difficult to do in
Post by Kari Hoijarvi
incremental development.
My solution is to use the debugger for the first run. Inspecting every
changed line while the program is actually running is simply
Post by Kari Hoijarvi
a better way to review.
Kari
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Bil Kleb
2004-08-02 22:24:41 UTC
Permalink
Post by Randy MacDonald
Whatever debuggers give you at human speed, TDD gives you at processor
speed. Computer-based assertions trump human-based inspections.
I've been coding ~4 years in Ruby. When I started, objects were new to
me and so was Ruby. I still don't even know how to invoke the Ruby
debugger because with TDD, I essentially build my own personal debugger.

Later,
--
Bil, Hampton, Virginia


To Post a message, send it to: ***@eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-***@eGroups.com

ad-free courtesy of objectmentor.com
Yahoo! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/

<*> To unsubscribe from this group, send an email to:
extremeprogramming-***@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Continue reading on narkive:
Loading...