Check out

http://users.vnet.net/wwake/xp/xp0001/index.shtml

This article by William Wake  on testing GUI's received hearty praise when first revealed to the XP community on Wiki.

Miroslav Novak BSc
Programmer/Analyst
efaSEMS
Capital Markets Automation

Suite 800, 605 5th Avenue SW
Calgary, Alberta, Canada  T2P 3H5
Direct:            +1(403)294-3005
Switchboard:   +1(403)265-6131
Fax:               +1(403)269-7711
Mailto:mnovak@...  
www.efasoftware.com

> -----Original Message-----
> From: tbragg@... [mailto:tbragg@...]
> Sent: Sunday, July 02, 2000 11:42 AM
> To: extremeprogramming@egroups.com
> Subject: [XP] Writing Tests First for GUI Programs
>
>
> I'm reading XP Explained and am intrigued with the XP concept
> (software developer for the past 30 years or so, now leading a team
> doing an e-commerce web site rollout).
>
> I'm puzzled by the "write the test first" approach as it relates to
> GUI software functionality (classes, etc. are clear).  Kent Beck
> seems to say it isn't worth building automated tests for GUIs because
> they're brittle, etc.  If so, how do you get to 100% automated
> testing for "only the things you care about working"?  Obviously we
> do care that the GUI works!  I did some surfing around but didn't see
> this topic addressed...
>
> XP should work in any language, so think about writing a VB program. 
> Traditional approach is, prototype the UI in VB, get customer
> acceptance, implement, test.  How do you get to testing earlier,
> particularly in a language like VB where the graphical stuff is so
> dominant?  Who writes the test, is it automated and if so, how?
>
> All feedback welcome, thanks!
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>

Jean-Henri Duteau wrote:

> At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> >My own solution would be not to create user stories, but to maintain the
> >integrity and completeness of the data in the beginning (when there isn't
> >too much of it) and get rid of what turns out not to be needed later.
>
> And who's paying for this?  The customer has already told you "I Don't Want
It!".  He's not willing to pay for the user stories / programming time that it
takes you to store this data, even if you think he should.

I agree, if I bring it up and the customer understands what I'm saying and
doesn't want it, it shouldn't go in. My fear is that I *won't* bring it up to
the customer because I *haven't* foreseen the necessity for it.

What would make me less afraid?

-Kay

I'm going to be doing a lot of script programming soon, and I thought
I'd check out the unit test frameworks for Python and Perl.

The documentation on the Perl unit test by Cayte Lindner is pretty
sparse ... I was wondering if anyone had experience with it and could
share their thoughts?

With Python, there seem to be a lot of choices ... Any thoughts on which
to use?  There's one from Cayte, one from Stephen Purcell, and now one
from Bob Martin (based on Cayte's).  At XP Immersion 3, Kent Beck
mentioned that he and Guido van Rossum had written a pyUnit, also,
although I don't see where that is available ...

Are there any others that might not be posted to xprogramming.com (I
noticed that OmPyUnit wasn't there, for example, and I haven't seen a
hint as to Kent's and Guido's)?  Anyway, I'm not installing xUnits for
these until later this week, so I thought I'd ask her for opinions
first.

Thanks!

Jen

----- Original Message -----
From: "Jean-Henri Duteau" <jeand@...
>
> Unless you're paying for the project out of your own pocket, then again I
re-iterate:  If the customer doesn't want it, then it doesn't go in.

Of course, that's absolutely true. However, we're not doing our job if we go
in with an attitude of blame-avoidance, rather than being as helpful as we
can. We know more about creating software than the client. But at the end of
the day, if the client doesn't want to pay for something, we don't do it. I
don't think anyone has said otherwise.

----- Original Message -----

> At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> >My own solution would be not to create user stories, but to maintain the
> >integrity and completeness of the data in the beginning (when there isn't
> >too much of it) and get rid of what turns out not to be needed later.
>
> And who's paying for this?  The customer has already told you "I Don't
Want It!".

Woah, woah, woah. :) Who said the customer said he didn't want it?

He can't say yes or no unless you suggest it. You can't suggest everything,
and YAGNI would say don't suggest collecting data that isn't needed.

----- Original Message -----
From: "Jim Murphy" <murphyjr@...>
> In the fax number example, if the fax number was not used to send
> information to the customer, there was no validation and no hint that the
> data was either good or bad.

I don't see the distinction. No matter whether you ask for the fax number
now or ask for it later, you can only really validate it when you use it for
something. The point at which you collected it doesn't seem relevant.

In any event, this argument doesn't apply to data that is impossible to
produce.

> I guess I'd have to go along with the camp that says to make the customer
> aware of the pro's and con's of saving data which is not currently needed,
> and allow the customer to make the best business decision.

I'm a member of that camp. :)

Let's step back to the year 2000 problem
when apparently a big problem arose because
programmers assigned two characters not four for the year.

If we are really interested in finger pointing,
who was to blame

1 the analyst who didn't mention that the program might fail in 2000?
or
2 the customer who didn't insist on year 2000 compliant stuff?

or is there another culprit?

keith




----- Original Message -----
From: "Mark Wilden" <mark@...>
To: <extremeprogramming@egroups.com>
Sent: Sunday, July 02, 2000 7:36 PM
Subject: Re: [XP] Re: Data Collection


> ----- Original Message -----
>
> > At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> > >My own solution would be not to create user stories, but to maintain
the
> > >integrity and completeness of the data in the beginning (when there
isn't
> > >too much of it) and get rid of what turns out not to be needed later.
> >
> > And who's paying for this?  The customer has already told you "I Don't
> Want It!".
>
> Woah, woah, woah. :) Who said the customer said he didn't want it?
>
> He can't say yes or no unless you suggest it. You can't suggest
everything,
> and YAGNI would say don't suggest collecting data that isn't needed.
>
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>
>

At 04:36 PM 7/2/2000 -0700, Mark Wilden wrote:
>He can't say yes or no unless you suggest it. You can't suggest everything,
>and YAGNI would say don't suggest collecting data that isn't needed.

YAGNI is about doing, not about suggesting.  Specifically, YAGNI says
"don't put code in the system that you don't need to do today's stories".

If anyone on the project has an idea that might be a good one, the
Communication value says they should communicate it. And the customers
decide what will be done.

Ron Jeffries
www.XProgramming.com

At 07:50 PM 7/2/2000 -0400, Keith Paton wrote:
>If we are really interested in finger pointing,
>who was to blame
>
>1 the analyst who didn't mention that the program might fail in 2000?
>or
>2 the customer who didn't insist on year 2000 compliant stuff?
>
>or is there another culprit?

If the programmer thought of it and didn't mention it, he violated the
communication value.
If the customer knew about it and didn't schedule the story, he may have
made a mistake.

Being prepared to lay the blame is not part of XP. Communication is,
customer making product choices is. We're human, we'll make mistakes.

The cause of the Y2K problem, by the way, was in violating the Once and
Only Once rule, and in not having enough tests. But who knew? The book
wasn't out yet.

Ron Jeffries
www.XProgramming.com

I agree - finger pointing and blame are perhaps a poor choice of words

However when we learn from past mistakes we traditionally use the form of
words

it was because of X that Y happened

and the step from here to the notion of blaming X for Y is but a short one.

Keith
----- Original Message -----
From: "Ron Jeffries" <ronjeffries@...>
To: <extremeprogramming@egroups.com>
Sent: Sunday, July 02, 2000 8:09 PM
Subject: Re: [XP] Re: Data Collection


> At 07:50 PM 7/2/2000 -0400, Keith Paton wrote:
> >If we are really interested in finger pointing,
> >who was to blame
> >
> >1 the analyst who didn't mention that the program might fail in 2000?
> >or
> >2 the customer who didn't insist on year 2000 compliant stuff?
> >
> >or is there another culprit?
>
> If the programmer thought of it and didn't mention it, he violated the
> communication value.
> If the customer knew about it and didn't schedule the story, he may have
> made a mistake.
>
> Being prepared to lay the blame is not part of XP. Communication is,
> customer making product choices is. We're human, we'll make mistakes.
>
> The cause of the Y2K problem, by the way, was in violating the Once and
> Only Once rule, and in not having enough tests. But who knew? The book
> wasn't out yet.
>
> Ron Jeffries
> www.XProgramming.com
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>
>

At 08:50 PM 7/2/2000 -0400, Keith Paton wrote:
>I agree - finger pointing and blame are perhaps a poor choice of words
>However when we learn from past mistakes we traditionally use the form of
>words
>it was because of X that Y happened
>and the step from here to the notion of blaming X for Y is but a short one.

Yes. As someone who always sees a way to do better - and who can't seem to
resist making the suggestion - I find that people often hear personal blame
when I'm just talking about the code, what could make it better, what could
test it better.

Our behavior produces our results. For better results, it seems to me that
we need better behavior. But often, it seems we'd rather not know. <sigh>



Ron Jeffries
www.XProgramming.com

Miroslav,

Thanks, that was exactly the kind of feedback I was looking for.
It's great to know you guys are here...

-Tom

--- In extremeprogramming@egroups.com, Miroslav Novak <mnovak@e...>
wrote:
> Check out
>
> http://users.vnet.net/wwake/xp/xp0001/index.shtml
>
> This article by William Wake  on testing GUI's received hearty
praise when
> first revealed to the XP community on Wiki.
>
> Miroslav Novak BSc
> Programmer/Analyst
> efaSEMS
> Capital Markets Automation
>
> Suite 800, 605 5th Avenue SW
> Calgary, Alberta, Canada  T2P 3H5
> Direct:            +1(403)294-3005
> Switchboard:   +1(403)265-6131
> Fax:               +1(403)269-7711
> Mailto:mnovak@e...
> www.efasoftware.com
>
>
>
> > -----Original Message-----
> > From: tbragg@a... [mailto:tbragg@a...]
> > Sent: Sunday, July 02, 2000 11:42 AM
> > To: extremeprogramming@egroups.com
> > Subject: [XP] Writing Tests First for GUI Programs
> >
> >
> > I'm reading XP Explained and am intrigued with the XP concept
> > (software developer for the past 30 years or so, now leading a
team
> > doing an e-commerce web site rollout).
> >
> > I'm puzzled by the "write the test first" approach as it relates
to
> > GUI software functionality (classes, etc. are clear).  Kent Beck
> > seems to say it isn't worth building automated tests for GUIs
because
> > they're brittle, etc.  If so, how do you get to 100% automated
> > testing for "only the things you care about working"?  Obviously
we
> > do care that the GUI works!  I did some surfing around but didn't
see
> > this topic addressed...
> >
> > XP should work in any language, so think about writing a VB
program.
> > Traditional approach is, prototype the UI in VB, get customer
> > acceptance, implement, test.  How do you get to testing earlier,
> > particularly in a language like VB where the graphical stuff is
so
> > dominant?  Who writes the test, is it automated and if so, how?
> >
> > All feedback welcome, thanks!
> >
> >
> >
> >
> > To Post a message, send it to:   extremeprogramming@e...
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@e...
> >
> > Ad-free courtesy of objectmentor.com
> >

Well... sure, "traditional approach" is waterfall in this case.

Thanks, there is a lot to think about in what you wrote... and you're
right, that's exactly how most VB programming is done.   ;-)

--- In extremeprogramming@egroups.com, "Phlip" <phlip@p...> wrote:
> From: <tbragg@a...>
>
> > XP should work in any language, so think about writing a VB
program.
> > Traditional approach is, prototype the UI in VB, get customer
> > acceptance, implement, test.  How do you get to testing earlier,
> > particularly in a language like VB where the graphical stuff is so
> > dominant?  Who writes the test, is it automated and if so, how?
>
> WaterFall rears its ugly head in many ways. Look at what you wrote:
Define
> the UI, get it accepted, write all the code behind it, test that
code. You
> might as well say your first step is to "deliver an analysis
document".
> Classic WaterFall is "analyze, design, implement, test".
>
> Snowing the customer - with either a quicky stage-prop UI, or a
bunch of
> technobabble in an "analysis document" - is fun for short-term
gains, but
> your crows will not come home to roost enough for you.
>
> Specifically, the bane of all VB-style writing is the Drill-Down
approach to
> adding code. You paint a screen, guessing at every control you'l
need, then
> you go in and write callback code under each control wiring them all
> together. This makes it easier to accidentally scatter your
business logic
> all over the place.
>
> The best way to do it is to iterate your customer acceptance with
real
> features. Take the time you would have spent painting controls, and
spend it
> implementing a single, real, target feature. Write its test code
_first_,
> then give it a simple UI: A window with a single button saying "do
it". If
> the user expresses curiosity about a real UI, draw a quick picture
of it
> with an art program. If the user expresses curiosity about the next
feature
> after this first one, you have customer acceptance.
>
> > I'm puzzled by the "write the test first" approach as it relates
to
> > GUI software functionality (classes, etc. are clear).
>
> UI controls aren't classes?
>
> > Kent Beck
> > seems to say it isn't worth building automated tests for GUIs
because
> > they're brittle, etc.  If so, how do you get to 100% automated
> > testing for "only the things you care about working"?  Obviously
we
> > do care that the GUI works!  I did some surfing around but didn't
see
> > this topic addressed...
>
> The Best of Both Worlds: All our UI toolkits have been built using
> test-first principles. This leaves in just enough hooks for our
test rigs to
> inspect windows as easily as they inspect object members.
>
> Barring that, test things which are likely to break. Don't test
getters and
> setters. If all your UI callback functions are short, they qualify
as data
> transport functions with very low likelyhood to break.
>
> Further, test things which are likely to break _obscurely_, with no
obvious
> symptoms right away. How many times (in VB land) have we said, "Oh,
don't
> worry about that bug - it's a display bug". We mean it's in the UI
code, not
> deeper down. If it's easy to spot when inspecting the UI, the risk
we'l ship
> this bug is lower.
>
> Put all those rules together, and in practice most folks just skip
the UI
> and only always automatically test everything else. That's bad
advice, but I
> follow it too ;-)
>
>  Phlip
> ======= http://users.deltanet.com/~tegan/home.html =======

From: Tom Bragg


> ...and you're
> right, that's exactly how most VB programming is done.

But _I've_ certainly never done it that way!

8-)

  Phlip
======= http://users.deltanet.com/~tegan/home.html =======

The editor of Addison Wesley in Germany sent me the
translation of "XP Explained", and I must admit
I'm not pleased with what the translator did to the
original XP vocabulary.

I'd ask any german-speaking folks on this list to
have a look at the vocabulary and make suggestions
for further improvement.

The discussion is going on over on the xp-forum:

   http://www.egroups.com/message/xp-forum/731?&start=731
   mailto:xp-forum@egroups.com

Frank

Way behind in my reading so I've only recently been going through the
May/June 2000 issue of IEEE Software.

I thought the article "Using Different Communication Media in
Requirements Negotiation" was interesting.  For one thing, I was
actually one of the students that participated and another thing, she
found that a particular distributed communication setting (faciliator
and customer 1 on one site, system analyst and customer 2 on the
other site) was more effective than face-to-face.  One proposed
explanation is that separating the customer with conflicting
interests allowed for less emotional negotiation (I'm reminded
suddenly of a User Friendly story line...).

I was wondering if anyone had any comments on this, especially
Alistair.

As a side note, I played the role of system analyst on the D1 setup
which apparently turned out to be the best one.  I'm sure that my mad
negotiation skillz didn't skew the results too much though... :-)

>   Date: Fri, 30 Jun 2000 16:25:37 -0500
>   From: "Morris, Chris" <ChrisM@...>
>Subject: RE: Schema refactoring
>
>I've worked on a project where I spent a lot of time rolling my own middle
>layer instead of taking advantage of existing data-aware components. Mostly,
>that was wasted time (YAGNI) - in that case.
>
>Could it be argued that starting off with a middle layer is good? Surely,
>it'd help me out now - all my database code is decentralized - that makes it
>hard to refactor the schema.

Refactoring and OnceAndOnlyOnce should help here.  You might not write that
layer in to the system for the first story you implement but soon after as it
becomes apparent that you do need it you should refactor into a separate layer.
A waste of time when you could have done it that way from the start?  Not
necessarily.  At this point you probably have more of an idea as to how this
middle layer should work.  If you had of done it at the start you probably would
be making too many guesses as to how it should work.

-- Glen
-- trinexus@...




_____________________________________________________________________
CAUTION - This message may contain privileged and confidential
information intended only for the use of the addressee named above.
If you are not the intended recipient of this message you are hereby
notified that any use, dissemination, distribution or reproduction
of this message is prohibited. If you have received this message in
error please notify Ansett Australia immediately. Any views expressed
in this message are those of the individual sender and may not
necessarily reflect the views of Ansett Australia.
ABN Ansett Australia Ltd 37 004 209 410
ABN Ansett International Ltd 72 060 622 460
_____________________________________________________________________

=From: "Marco Dorantes" <marcodorantes@...>
=
=Hi!
=
=Certainly that section of code isn't enough to see the process we do to get
=it. We needed to show the atm network as a hierarchy of Organization(s) that
=has Network(s), that has ATM(s) that has modules/devices, each node has
=properties, operations and notifications.
=
=We try to start simple, using just Composite, then we found ourselves
=duplicating almost the same code for each node/subnode pair, then we want to
=isolate the UI objects from the application objects by means of UI objects
=using NodeInterface and TreeInterface (which hold a Composite relationship),
=so all our application objects must implement these interfaces.
=
=More over, all application objects must be persistent, so there are some
=more common interfaces for our application objects to implement, that is,
=there are several roles in common the application objects must play, so the
=abstract base represent a common base that groups the interfaces that all
=application objects implement

hi Marco,
i think we have a misunderstanding, i was talking only about the use
of the word Abstract, from your earlier example ...

class AbstractATMNetwork : public
AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory> {
public:
     AbstractATMNetwork(const char* n,ModuleAbstractFactory&
f):AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory>(n,f)
{}
     AbstractATMNetwork(const char* n,ModuleAbstractFactory&
f,Persistence::IFolder*
fold):AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory>(n,f\
,fold)
{}
     virtual ~AbstractATMNetwork();

private:
};


i dont see the need for it.  you dont do ...

virtual ~AbstractDestructorATMNetwork();

do you?  so why put Abstract in there?  what does it gain you?
c

=From: Eric Hodges <eric.hodges@...>
=
=Putting an I in front of interface names has helped me out a lot.  I don't
=really care if something is abstract, but for interfaces it makes talking
=about them easier and more explicit.  When someone asks how to access a
=class of mine, I say "IWhatever" and they know it's an interface.

i dont see how, you could just say "Whatever" and they'd still have to look
at the code to use it, i dont see what _extra_ is gained from the use of I.
i've been thinking about this issue a bit recently because one of our
naming standards puts T on the end of a templated class, and i cant
think of any good reason for it...
c

ps if this is off-topic feel free to email me direct.

André,
We usually follow one of three approaches:
1) If the database interface can be made simple, we separate it as an interface
(and
layer) of its own and implement a dummy which is mainly used for the unit tests.
The
dummy can get its data from text files or serialized objects. Only a few tests
remain
to be executed against a real database (connecting, simple read, simple write).
2) If all unit tests must be run against the real DB - since a dummy would be
too
expensive to develop - we create the test data in setUp() and get rid of it in
tearDown(), e.g. by a starting a transaction in setUp() and rolling back in
tearDown().

3) In rare cases we had to deal with a test database containing more or less
real data
because it would have been too costly to create large amounts and complex
structures of
the required data. Keeping those test DBs in a consistent state is very
difficult,
though.

If necessary you should combine the different approaches for different aspects
of the
system.

Johannes Link
--
Andrena Objects

André Claaßen wrote:

> Hello,
>
> Our project team is new to XP. We try XP on a client/server Application
> written in VC++ and VB.
>
> Now we introduce UnitTests in our project, to improve quality and set up a
> base for refactoring. I have a question for testing data access objects.
> Should I generate some test data at the start of Unit-Test and remove it
> later after finishing the test? Is there a simpler way?
>
> In one article, there was a tip for spoofing test data in the objects.
>
> many thanks,
>         A. Claassen
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com

Eric Hodges wrote:
>
> Putting an I in front of interface names has helped me out a lot.  I don't
> really care if something is abstract, but for interfaces it makes talking
> about them easier and more explicit.  When someone asks how to access a
> class of mine, I say "IWhatever" and they know it's an interface.

I disagree strongly with this approach. I disagree on two levels.
Firstly, for good abstractions, you will be passing around the interface
class most of the time. For example when I use the Java "Map" interface
class, I always refer to it as a Map, rather than a HashMap where
appropriate because it makes the code more general. The code only cares
that it is dealing with a Map. Thus it should be the interface which has
the plain descriptive name "Map", and it should be the specific
implementations that are embellished with the extra "HashMap" or
"MapImpl". Secondly, lots of interfaces will use these interface classes
as return results etc, and people reading the Javadoc really don't want
to know that they happen to be interfaces or they happen to be real
classes. All they want to do is pass them around and call methods on
them. What if you decide later it doesn't need to be an interface but
should be a real class?

Marco Dorantes wrote:
> this is part of a header file of the next release of our ATM network
> monitoring software,
>
> #include "ATMInterface.h"
> #include "ATMNetworkInterface.h"
> #include "ModuleAbstractFactory.h"
> #include "AbstractModule.h"
>
> class AbstractATMNetwork : public
> AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory> {
> public:
>     AbstractATMNetwork(const char* n,ModuleAbstractFactory&
> f):AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory>(n,f)
> {}
>     AbstractATMNetwork(const char* n,ModuleAbstractFactory&
> f,Persistence::IFolder*
>
fold):AbstractModule<ATMNetworkInterface,ATMInterface,ModuleAbstractFactory>(n,f\
,fold)
> {}
>     virtual ~AbstractATMNetwork();
>
> private:
> };
>
> We name the classes adding "Abstract" or "Interface", so the intent can be
> cleary in code.

I think adding Abstract to the name of the class is way overkill just to
document this fact in the code. Most users of the class won't care at
all that it happens to be abstract. Perhaps unfortunately C++ doesn't
have an abstract keyword like Java. Don't let this stop you though...

#define abstract


abstract class ATMNetwork : public
      Module<ATMNetwork,ATM, ModuleFactory> {
}

Ron Jeffries wrote:

> If anyone on the project has an idea that might be a good one, the
> Communication value says they should communicate it. And the customers
> decide what will be done.

The beauty of XP lies in its simplicity. The risk of building the wrong product
vanishes once you accept the principle that the customer has final
responsibility for
what gets built. I agree with this wholeheartedly. I have seen what happens when
the
responsibilities of development and customer get blurred -- and I don't want to
go
there again.

I am curious to push the limits of XP a little bit, since I am trying to use XP
for a
product rather than for a single customer, and in this case I have to consider
the role
of the customer/product manager carefully. Discovering, ranking and balancing
the needs
of hundreds of customers, not to mention different roles (accountant, data
entry, and
business decision maker), does not seem trivial. I think the activity is called
analysis and I think someone here is going to have to learn how to do it. Any
pointers
from those more experienced would be welcome :-)

Thanks,
-Kay

I'll take VMS over Multics any day of the week.

It's a shame that it's 2000 and the offspring of those ancient OSs are our
only choices.


----- Original Message -----
From: "Steve Freeman" <steve@...>
To: <extremeprogramming@egroups.com>
Sent: Saturday, July 01, 2000 12:00 PM
Subject: Re: [XP] Re: XP and OS design


> From: Dave Thomas <Dave@...>
> > Actually, Multics is alive and well and living inside a range of
> > fault-tolerant computers from Stratus. It was renamed VOS, but at its
> > core, the OS is Multics. It's one of the best operating systems I've
> > come across for TP-style applications.
>
> So that's where it went! In its day, a great environment to develop in.
It's a shame that Dave Cutler reimplemented VMS rather than Multics.
>
> Steve
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>
>

<< May/June 2000 issue of IEEE Software.
  ..."Using Different Communication Media in
  Requirements Negotiation"...
  found that a particular distributed communication setting (faciliator
  and customer 1 on one site, system analyst and customer 2 on the
  other site) was more effective than face-to-face.  One proposed
  explanation is that separating the customer with conflicting
  interests allowed for less emotional negotiation (I'm reminded
  suddenly of a User Friendly story line...).
      I was wondering if anyone had any comments on this, especially
  Alistair. >>

I have been encountering some some similar cases
and am collecting notes on them.  One woman said that
she is more effective over the phone exactly because the communication
medium is thinner - - she doesn't overpower the other people with her
personality.  This sounds like what you are relaying.
    I noticed people in Finland sending SMS messages to each other's
cell phones rather than calling.  One person said that is so he doesn't
have to react in real time, but can think about it, also that he doesn't
have to give out emotional reactions to the message right away.
   I find this all very interesting, and am busy storing incidents away
like a squirrel until some decent pattern or theory shows up.
    I'll chase down that article and read it (someday soon).
cheers

Alistair Cockburn
Humans and Technology

7691 Dell Rd.
Salt Lake City, UT 84121
Phone: 801.947.9275
write to: arc@...
http://members.aol.com/acockburn

----- Original Message -----
From: "Chris Bitmead" <chrisb@...>
To: <extremeprogramming@egroups.com>
Sent: Sunday, July 02, 2000 11:26 PM
Subject: Re: naming (was Re: [XP] Abstract Classes


> Eric Hodges wrote:
> >
> > Putting an I in front of interface names has helped me out a lot.  I
don't
> > really care if something is abstract, but for interfaces it makes
talking
> > about them easier and more explicit.  When someone asks how to access a
> > class of mine, I say "IWhatever" and they know it's an interface.
>
> I disagree strongly with this approach. I disagree on two levels.
> Firstly, for good abstractions, you will be passing around the interface
> class most of the time. For example when I use the Java "Map" interface
> class, I always refer to it as a Map, rather than a HashMap where
> appropriate because it makes the code more general. The code only cares
> that it is dealing with a Map. Thus it should be the interface which has
> the plain descriptive name "Map", and it should be the specific
> implementations that are embellished with the extra "HashMap" or
> "MapImpl". Secondly, lots of interfaces will use these interface classes
> as return results etc, and people reading the Javadoc really don't want
> to know that they happen to be interfaces or they happen to be real
> classes. All they want to do is pass them around and call methods on
> them. What if you decide later it doesn't need to be an interface but
> should be a real class?

You just change it.

Ah, I think there's a language bias behind our different viewpoints.  I
first saw it in MFC source, all in C++.  It's part of Microsoft's naming
standard.  I don't like the "C" in front of classes, but since C++ doesn't
have an interface keyword, classes starting with "I" are more easily
recognizable as interfaces.  I didn't use the I prefix for Java code until
after I'd spent a few years doing VC++ COM programming.

tbragg@... schrieb:
>
> I'm puzzled by the "write the test first" approach as it relates to
> GUI software functionality (classes, etc. are clear).  Kent Beck
> seems to say it isn't worth building automated tests for GUIs because
> they're brittle, etc.  If so, how do you get to 100% automated
> testing for "only the things you care about working"?  Obviously we
> do care that the GUI works!  I did some surfing around but didn't see
> this topic addressed...

It's true, this topic is not very well adressed. I just tried some GUI
capture/playback testtools like Mercury's WinRunner and Rational's
TeamTest. They promise to automate GUI testing. It is a lot of work though
and you need to be carefull to create tests that don't break too easy if
the GUI changes. It is really an own software development project. I might
use these tools to automate a couple of Smoketests. But it doesn't make
sense to automate the whole GUI. Way too much work and too little
packback.

If you application is well tested at the functionality level underneath a
testteam can find the GUI bugs very quickly.
>From what I heard doing this manual is still more efficient.

To test the functionality of the application it makes sense to introduce
an interface for which you can write the tests.

> XP should work in any language, so think about writing a VB program.
> Traditional approach is, prototype the UI in VB, get customer
> acceptance, implement, test.  How do you get to testing earlier,
> particularly in a language like VB where the graphical stuff is so
> dominant?  Who writes the test, is it automated and if so, how?

Don't know much about VB development, sorry.

Malte

----- Original Message -----
From: <c@...>
> =From: Eric Hodges <eric.hodges@...>
> =Putting an I in front of interface names has helped
>= me out a lot.  I don't really care if something is abstract,
>= but for interfaces it makes talking about them easier
>= and more explicit.  When someone asks how to access a
> =class of mine, I say "IWhatever" and they know it's an
>= interface.
>
> i dont see how, you could just say "Whatever" and they'd
> still have to look at the code to use it, i dont see what
> _extra_ is gained from the use of I.  i've been thinking
> about this issue a bit recently because one of our naming
> standards puts T on the end of a templated class, and i cant
> think of any good reason for it...

I lean against implementation revealing naming conventions
like those, so that I can take up the challenge of making
better names.  In Kent Beck's Smalltalk Best Practice Patterns
book, he talks about the names of methods should reveal
your intentions.  With practice, you find that you often don't
have to look at method implementations to understand
what is going on.

Another advantage to avoiding these "implementation tags"
in names is that ends up closing your code to implementation
changes.  What happens when you refactor and discover
that an interface is overkill; you just need a class?  Without
a good refactoring tool, you are stuck changing IWhatever
to Whatever everywhere.

Michael



---------------------------------------------------
Michael Feathers  mfeathers@...
Object Mentor Inc.  www.objectmentor.com
Training/Mentoring/Development
-----------------------------------------------------
"You think you know when you can learn, are more sure when
you can write, even more when you can teach, but certain when
you can program. " - Alan Perlis

Hi,

these are the guidelines we use. We use the first one. The reason
for the first one is that it supports evolution best. From a concrete
name through a code-reuse-abstracted superclass to an interface.
Typically we start out with the simplest thing that could possibly
work and extend from there as needed.

Dirk


Interface and Class Naming Conventions

Consider the example of an interface for name objects, an abstract
superclass that partially implements the interface, and some
subclasses of the abstract superclass that implement the missing holes
inherited from the superclass.

Primary convention

The convention goes like this:

- Interface. No prefix, just the primary name, for example, "Name".
- Abstract class. Gets prefixed with "Abstract", for example
"AbstractName".
- Concrete class. Just give them a telling name, for example,
"StringName" or "VectorName".
- Default implementation class. Gets prefixed with "Default",
"Standard", or "Simple".

Before we decided to use this convention, we had tried both of the
following variants. They are still justified in special circumstances.

Backup convention: prefixing interfaces

The convention goes like this:

- Interface. Gets prefixed with "I", for example, "IName".
- Abstract class. Gets prefixed with "Abstract", for example
"AbstractName".
- Concrete class. Just give them a telling name, for example,
"StringName" or "VectorName".
- Default implementation class. Gets prefixed with "Default",
"Standard", or "Simple".

This one reads natural and can be used if you insist on making
interfaces easily recognizable by their name.

Backup convention: postfixing implementations

The convention goes like this:

- Interface. No prefix at all, just the regular name, for example,
"Name".
- Abstract class. Gets postfixed with "DefImpl", for example,
"NameDefImpl".
- Concrete class. Gets postfixed with "Impl", for example,
"StringNameImpl" or "VectorNameImpl".
- Default implementation class. Gets prefixed with "Default", etc. and
postfixed with Impl.

This one is typically used if you need an interface for every class,
for example, in a distributed system. In the Geo system, we generated
proxies and adapters on the fly and thus required interfaces. San
Francisco of IBM does a similar thing.

----
Publications, work, and other stuff: www.riehle.org
JValue, a Java framework for Value Objects: www.jvalue.org
Advanced Java development guidelines: www.riehle.org/java

Listen X-Treme,  Twice I've asked you kindly to stop sending this e-mail.  I
followed you instructions and this is as nice as I can be.  Please remove me
from all of your mailing lists at once.  Thank you extremely - Steve

-----Original Message-----
From: extremeprogramming@egroups.com
[mailto:extremeprogramming@egroups.com]
Sent: Sunday, July 02, 2000 9:49 PM
To: extremeprogramming@egroups.com
Subject: [XP] Digest Number 196


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

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

Ad-free courtesy of objectmentor.com
------------------------------------------------------------------------

There are 25 messages in this issue.

Topics in this digest:

       1. Yahoo! Auto Response
            From: <christopher_seguin@...>
       2. UnitTest in an DBMS Environment?
            From: André Claaßen <a.claassen@...>
       3. Writing Tests First for GUI Programs
            From: tbragg@...
       4. Re: Data Collection
            From: Jean-Henri Duteau <jeand@...>
       5. Re: Data Collection
            From: Jean-Henri Duteau <jeand@...>
       6. Re: Re: Schema Change / Data Collection (was C#)
            From: "Jim Murphy" <murphyjr@...>
       7. Re: Re: Data Collection
            From: Ron McCabe <rmccabe@...>
       8. Re: Digest Number 195
            From: dmb11@...
       9. Re: Writing Tests First for GUI Programs
            From: "Phlip" <phlip@...>
      10. RE: Writing Tests First for GUI Programs
            From: Miroslav Novak <mnovak@...>
      11. Re: Re: Data Collection
            From: Kay Johansen <kay@...>
      12. Unit testing for Python and Perl
            From: Jen Wu <jen@...>
      13. Re: Re: Data Collection
            From: "Mark Wilden" <mark@...>
      14. Re: Re: Data Collection
            From: "Mark Wilden" <mark@...>
      15. Re: Re: Schema Change / Data Collection (was C#)
            From: "Mark Wilden" <mark@...>
      16. Re: Re: Data Collection
            From: "Keith Paton" <paton@...>
      17. Re: Re: Data Collection
            From: Ron Jeffries <ronjeffries@...>
      18. Re: Re: Data Collection
            From: Ron Jeffries <ronjeffries@...>
      19. finger pointing vs learning from our mistakes
            From: "Keith Paton" <paton@...>
      20. Re: finger pointing vs learning from our mistakes
            From: Ron Jeffries <ronjeffries@...>
      21. Re: Writing Tests First for GUI Programs
            From: "Tom Bragg" <tbragg@...>
      22. Re: Writing Tests First for GUI Programs
            From: "Tom Bragg" <tbragg@...>
      23. Re: Re: Writing Tests First for GUI Programs
            From: "Phlip" <phlip@...>
      24. German translation of "XP Explained"
            From: Frank Westphal <westphal@...>
      25. Using Different Communication Media in Requirements Negotiation
            From: "Jason Yip" <j.c.yip@...>


________________________________________________________________________
________________________________________________________________________

Message: 1
    Date: Sun, 2 Jul 2000 06:48:48 -0700 (PDT)
    From: <christopher_seguin@...>
Subject: Yahoo! Auto Response

Hi,

Unfortunately due to a death in my family, I will take
longer than usual to respond to your e-mail.  Please
bear with me.

Chris

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


Original Message:


Received: from mail.acm.org (199.222.69.4)
   by mta139.mail.yahoo.com with SMTP; 02 Jul 2000 06:48:47 -0700 (PDT)
Received: from hh.egroups.com (hh.egroups.com [208.50.144.88])
	 by mail.acm.org (8.9.3/8.9.3) with SMTP id JAA51174
	 for <seguin@...>; Sun, 2 Jul 2000 09:47:26 -0400
X-eGroups-Return:
sentto-1505409-195-962545714-seguin=acm.org@returns.onelist.com
Received: from [10.1.10.143] by hh.egroups.com with NNFMP; 02 Jul 2000
13:48:34 -0000
MIME-Version: 1.0
Message-ID: <962545714.27678@egroups.com>
Mailing-List: list extremeprogramming@egroups.com; contact
extremeprogramming-owner@egroups.com
Delivered-To: mailing list extremeprogramming@egroups.com
Precedence: bulk
List-Unsubscribe: <mailto:extremeprogramming-unsubscribe@egroups.com>
Date: 2 Jul 2000 13:48:34 -0000
From: extremeprogramming@egroups.com
Reply-To: extremeprogramming@egroups.com
To: extremeprogramming@egroups.com
Subject: [XP] Digest Number 195
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com



________________________________________________________________________
________________________________________________________________________

Message: 2
    Date: Sun, 2 Jul 2000 16:26:03 +0200
    From: André Claaßen <a.claassen@...>
Subject: UnitTest in an DBMS Environment?

Hello,

Our project team is new to XP. We try XP on a client/server Application
written in VC++ and VB.

Now we introduce UnitTests in our project, to improve quality and set up a
base for refactoring. I have a question for testing data access objects.
Should I generate some test data at the start of Unit-Test and remove it
later after finishing the test? Is there a simpler way?

In one article, there was a tip for spoofing test data in the objects.

many thanks,
	 A. Claassen



________________________________________________________________________
________________________________________________________________________

Message: 3
    Date: Sun, 02 Jul 2000 17:42:09 -0000
    From: tbragg@...
Subject: Writing Tests First for GUI Programs

I'm reading XP Explained and am intrigued with the XP concept
(software developer for the past 30 years or so, now leading a team
doing an e-commerce web site rollout).

I'm puzzled by the "write the test first" approach as it relates to
GUI software functionality (classes, etc. are clear).  Kent Beck
seems to say it isn't worth building automated tests for GUIs because
they're brittle, etc.  If so, how do you get to 100% automated
testing for "only the things you care about working"?  Obviously we
do care that the GUI works!  I did some surfing around but didn't see
this topic addressed...

XP should work in any language, so think about writing a VB program.
Traditional approach is, prototype the UI in VB, get customer
acceptance, implement, test.  How do you get to testing earlier,
particularly in a language like VB where the graphical stuff is so
dominant?  Who writes the test, is it automated and if so, how?

All feedback welcome, thanks!



________________________________________________________________________
________________________________________________________________________

Message: 4
    Date: Sun, 02 Jul 2000 12:33:31 -0600
    From: Jean-Henri Duteau <jeand@...>
Subject: Re: Data Collection


>> If the customer doesn't ask for a very important piece of data up front
>and it bites them on the bum, that's not really our fault, is it?  If the
>customer doesn't think it's important, who are we to second-guess him?
>
>Because we're the analysts. Because we've done this before--perhaps many
>times.
So what????

Unless you're paying for the project out of your own pocket, then again I
re-iterate:  If the customer doesn't want it, then it doesn't go in.  It's
totally counter to XP as I see it to add stories to the project if the
customer doesn't want them, even if you think you know better.  Sure, stress
to the customer that you think this piece of data is very important.  But if
they pooh-pooh it, then you've tried and it doesn't go in.

To me, YAGNI is really a coding philosophy than a design philosophy.  Time
and time again, when I go to write some code and I'm faced with two ways of
doing it, I can do the simple thing or the thing that looks to the future.
YAGNI tells me to do the simple thing, because "You Ain't Gonna Need It!".
Does this apply to the Planning Game?  I don't think so.  In the Planning
Game, you and the customer throw out all the things you'll think you need,
estimate how long it will take to do each of them, and then the customer
chooses them.  If he does not choose the "Collect Important Piece of Data"
story, then out the window it goes.

Jean



________________________________________________________________________
________________________________________________________________________

Message: 5
    Date: Sun, 02 Jul 2000 12:37:04 -0600
    From: Jean-Henri Duteau <jeand@...>
Subject: Re: Data Collection

At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
>My own solution would be not to create user stories, but to maintain the
>integrity and completeness of the data in the beginning (when there isn't
>too much of it) and get rid of what turns out not to be needed later.

And who's paying for this?  The customer has already told you "I Don't Want
It!".  He's not willing to pay for the user stories / programming time that
it takes you to store this data, even if you think he should.

>Clearly, when you ship a customer a product, yet don't record the address
at
>that moment in time, you're losing data. So it would be a good idea to
>capture it "just in case". And "just in case" is anathema to YAGNI, but I
>think it can be essential for data collection.

But you brought it up in the beginning and the customer told you NO!

You'll have total egg on your face if you don't make your estimates because
you're doing work that the customer doesn't want you to, just because you
think you know better.

Jean



________________________________________________________________________
________________________________________________________________________

Message: 6
    Date: Sun, 2 Jul 2000 15:16:14 -0400
    From: "Jim Murphy" <murphyjr@...>
Subject: Re: Re: Schema Change / Data Collection (was C#)


----- Original Message -----
From: "Mark Wilden" <mark@...>
To: <extremeprogramming@egroups.com>
Sent: Saturday, July 01, 2000 12:59 PM
Subject: Re: [XP] Re: Schema Change / Data Collection (was C#)


>
> Perhaps not, maybe because some folks are concentrating too hard on the
> example of a fax number and not recognizing the general issue: how it can
be
> impossible to collect some kinds of data a posteriori. Not difficult--not
> embarrasing--but impossible.
>
>

I accept your argument that it is sometimes impossible to go back and obtain
data that was not saved along the way.  However, in my experience the only
thing worse (from a Business value perspective) than not having data is
having bad data or data of dubious quality.  Data which is not important at
the early stages of a system usually gets no feedback regarding its quality.
In the fax number example, if the fax number was not used to send
information to the customer, there was no validation and no hint that the
data was either good or bad.  Too frequently I've seen some PHB come up with
a "brilliant" to use data because it "exists" in the database idea (along
the lines of "Hey, but we saved the customer's fax number, so we can just
fax him a note to say his replacement kidneys are available..."), only to
discover that the data is wrong or obsolete.  In such cases, the cost of
verifying the integrity of the data was more than just trying to obtain it
once again.

I guess I'd have to go along with the camp that says to make the customer
aware of the pro's and con's of saving data which is not currently needed,
and allow the customer to make the best business decision.

Jim Murphy
murphyjr@...





________________________________________________________________________
________________________________________________________________________

Message: 7
    Date: Sun, 02 Jul 2000 13:24:59 -0600
    From: Ron McCabe <rmccabe@...>
Subject: Re: Re: Data Collection



Jean-Henri Duteau wrote:

> At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> >My own solution would be not to create user stories, but to maintain the
> >integrity and completeness of the data in the beginning (when there isn't
> >too much of it) and get rid of what turns out not to be needed later.
>
> And who's paying for this?  The customer has already told you "I Don't
Want It!".  He's not willing to pay for the user stories / programming time
that it takes you to store this data, even if you think he should.
>
> >Clearly, when you ship a customer a product, yet don't record the address
at
> >that moment in time, you're losing data. So it would be a good idea to
> >capture it "just in case". And "just in case" is anathema to YAGNI, but I
> >think it can be essential for data collection.
>
> But you brought it up in the beginning and the customer told you NO!
>
> You'll have total egg on your face if you don't make your estimates
because you're doing work that the customer doesn't want you to, just
because you think you know better.
>
> Jean
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com



________________________________________________________________________
________________________________________________________________________

Message: 8
    Date: Sun, 2 Jul 2000 15:49:56 -0400
    From: dmb11@...
Subject: Re: Digest Number 195

I will be on vacation from the week of July 4th.  Please direct any
questions/issues to:
      Area Person              Phone           ID
      PC   Rick Rose      743-2952  rgr2
      MPC  Shibin Hu      743-2981 sh10

Thanks, David



________________________________________________________________________
________________________________________________________________________

Message: 9
    Date: Sun, 2 Jul 2000 13:02:31 -0700
    From: "Phlip" <phlip@...>
Subject: Re: Writing Tests First for GUI Programs

From: <tbragg@...>

> XP should work in any language, so think about writing a VB program.
> Traditional approach is, prototype the UI in VB, get customer
> acceptance, implement, test.  How do you get to testing earlier,
> particularly in a language like VB where the graphical stuff is so
> dominant?  Who writes the test, is it automated and if so, how?

WaterFall rears its ugly head in many ways. Look at what you wrote: Define
the UI, get it accepted, write all the code behind it, test that code. You
might as well say your first step is to "deliver an analysis document".
Classic WaterFall is "analyze, design, implement, test".

Snowing the customer - with either a quicky stage-prop UI, or a bunch of
technobabble in an "analysis document" - is fun for short-term gains, but
your crows will not come home to roost enough for you.

Specifically, the bane of all VB-style writing is the Drill-Down approach to
adding code. You paint a screen, guessing at every control you'l need, then
you go in and write callback code under each control wiring them all
together. This makes it easier to accidentally scatter your business logic
all over the place.

The best way to do it is to iterate your customer acceptance with real
features. Take the time you would have spent painting controls, and spend it
implementing a single, real, target feature. Write its test code _first_,
then give it a simple UI: A window with a single button saying "do it". If
the user expresses curiosity about a real UI, draw a quick picture of it
with an art program. If the user expresses curiosity about the next feature
after this first one, you have customer acceptance.

> I'm puzzled by the "write the test first" approach as it relates to
> GUI software functionality (classes, etc. are clear).

UI controls aren't classes?

> Kent Beck
> seems to say it isn't worth building automated tests for GUIs because
> they're brittle, etc.  If so, how do you get to 100% automated
> testing for "only the things you care about working"?  Obviously we
> do care that the GUI works!  I did some surfing around but didn't see
> this topic addressed...

The Best of Both Worlds: All our UI toolkits have been built using
test-first principles. This leaves in just enough hooks for our test rigs to
inspect windows as easily as they inspect object members.

Barring that, test things which are likely to break. Don't test getters and
setters. If all your UI callback functions are short, they qualify as data
transport functions with very low likelyhood to break.

Further, test things which are likely to break _obscurely_, with no obvious
symptoms right away. How many times (in VB land) have we said, "Oh, don't
worry about that bug - it's a display bug". We mean it's in the UI code, not
deeper down. If it's easy to spot when inspecting the UI, the risk we'l ship
this bug is lower.

Put all those rules together, and in practice most folks just skip the UI
and only always automatically test everything else. That's bad advice, but I
follow it too ;-)

  Phlip
======= http://users.deltanet.com/~tegan/home.html =======




________________________________________________________________________
________________________________________________________________________

Message: 10
    Date: Sun, 2 Jul 2000 15:06:18 -0600
    From: Miroslav Novak <mnovak@...>
Subject: RE: Writing Tests First for GUI Programs

Check out

http://users.vnet.net/wwake/xp/xp0001/index.shtml

This article by William Wake  on testing GUI's received hearty praise when
first revealed to the XP community on Wiki.

Miroslav Novak BSc
Programmer/Analyst
efaSEMS
Capital Markets Automation

Suite 800, 605 5th Avenue SW
Calgary, Alberta, Canada  T2P 3H5
Direct:            +1(403)294-3005
Switchboard:   +1(403)265-6131
Fax:               +1(403)269-7711
Mailto:mnovak@...
www.efasoftware.com



> -----Original Message-----
> From: tbragg@... [mailto:tbragg@...]
> Sent: Sunday, July 02, 2000 11:42 AM
> To: extremeprogramming@egroups.com
> Subject: [XP] Writing Tests First for GUI Programs
>
>
> I'm reading XP Explained and am intrigued with the XP concept
> (software developer for the past 30 years or so, now leading a team
> doing an e-commerce web site rollout).
>
> I'm puzzled by the "write the test first" approach as it relates to
> GUI software functionality (classes, etc. are clear).  Kent Beck
> seems to say it isn't worth building automated tests for GUIs because
> they're brittle, etc.  If so, how do you get to 100% automated
> testing for "only the things you care about working"?  Obviously we
> do care that the GUI works!  I did some surfing around but didn't see
> this topic addressed...
>
> XP should work in any language, so think about writing a VB program.
> Traditional approach is, prototype the UI in VB, get customer
> acceptance, implement, test.  How do you get to testing earlier,
> particularly in a language like VB where the graphical stuff is so
> dominant?  Who writes the test, is it automated and if so, how?
>
> All feedback welcome, thanks!
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
> extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>


[This message contained attachments]



________________________________________________________________________
________________________________________________________________________

Message: 11
    Date: Sun, 02 Jul 2000 17:06:20 -0600
    From: Kay Johansen <kay@...>
Subject: Re: Re: Data Collection

Jean-Henri Duteau wrote:

> At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> >My own solution would be not to create user stories, but to maintain the
> >integrity and completeness of the data in the beginning (when there isn't
> >too much of it) and get rid of what turns out not to be needed later.
>
> And who's paying for this?  The customer has already told you "I Don't
Want It!".  He's not willing to pay for the user stories / programming time
that it takes you to store this data, even if you think he should.

I agree, if I bring it up and the customer understands what I'm saying and
doesn't want it, it shouldn't go in. My fear is that I *won't* bring it up
to the customer because I *haven't* foreseen the necessity for it.

What would make me less afraid?

-Kay



________________________________________________________________________
________________________________________________________________________

Message: 12
    Date: Sun, 02 Jul 2000 16:35:17 -0700
    From: Jen Wu <jen@...>
Subject: Unit testing for Python and Perl

I'm going to be doing a lot of script programming soon, and I thought
I'd check out the unit test frameworks for Python and Perl.

The documentation on the Perl unit test by Cayte Lindner is pretty
sparse ... I was wondering if anyone had experience with it and could
share their thoughts?

With Python, there seem to be a lot of choices ... Any thoughts on which
to use?  There's one from Cayte, one from Stephen Purcell, and now one
from Bob Martin (based on Cayte's).  At XP Immersion 3, Kent Beck
mentioned that he and Guido van Rossum had written a pyUnit, also,
although I don't see where that is available ...

Are there any others that might not be posted to xprogramming.com (I
noticed that OmPyUnit wasn't there, for example, and I haven't seen a
hint as to Kent's and Guido's)?  Anyway, I'm not installing xUnits for
these until later this week, so I thought I'd ask her for opinions
first.

Thanks!

Jen


________________________________________________________________________
________________________________________________________________________

Message: 13
    Date: Sun, 2 Jul 2000 16:33:29 -0700
    From: "Mark Wilden" <mark@...>
Subject: Re: Re: Data Collection

----- Original Message -----
From: "Jean-Henri Duteau" <jeand@...
>
> Unless you're paying for the project out of your own pocket, then again I
re-iterate:  If the customer doesn't want it, then it doesn't go in.

Of course, that's absolutely true. However, we're not doing our job if we go
in with an attitude of blame-avoidance, rather than being as helpful as we
can. We know more about creating software than the client. But at the end of
the day, if the client doesn't want to pay for something, we don't do it. I
don't think anyone has said otherwise.




________________________________________________________________________
________________________________________________________________________

Message: 14
    Date: Sun, 2 Jul 2000 16:36:57 -0700
    From: "Mark Wilden" <mark@...>
Subject: Re: Re: Data Collection

----- Original Message -----

> At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> >My own solution would be not to create user stories, but to maintain the
> >integrity and completeness of the data in the beginning (when there isn't
> >too much of it) and get rid of what turns out not to be needed later.
>
> And who's paying for this?  The customer has already told you "I Don't
Want It!".

Woah, woah, woah. :) Who said the customer said he didn't want it?

He can't say yes or no unless you suggest it. You can't suggest everything,
and YAGNI would say don't suggest collecting data that isn't needed.




________________________________________________________________________
________________________________________________________________________

Message: 15
    Date: Sun, 2 Jul 2000 16:41:11 -0700
    From: "Mark Wilden" <mark@...>
Subject: Re: Re: Schema Change / Data Collection (was C#)

----- Original Message -----
From: "Jim Murphy" <murphyjr@...>
> In the fax number example, if the fax number was not used to send
> information to the customer, there was no validation and no hint that the
> data was either good or bad.

I don't see the distinction. No matter whether you ask for the fax number
now or ask for it later, you can only really validate it when you use it for
something. The point at which you collected it doesn't seem relevant.

In any event, this argument doesn't apply to data that is impossible to
produce.

> I guess I'd have to go along with the camp that says to make the customer
> aware of the pro's and con's of saving data which is not currently needed,
> and allow the customer to make the best business decision.

I'm a member of that camp. :)



________________________________________________________________________
________________________________________________________________________

Message: 16
    Date: Sun, 2 Jul 2000 19:50:58 -0400
    From: "Keith Paton" <paton@...>
Subject: Re: Re: Data Collection

Let's step back to the year 2000 problem
when apparently a big problem arose because
programmers assigned two characters not four for the year.

If we are really interested in finger pointing,
who was to blame

1 the analyst who didn't mention that the program might fail in 2000?
or
2 the customer who didn't insist on year 2000 compliant stuff?

or is there another culprit?

keith




----- Original Message -----
From: "Mark Wilden" <mark@...>
To: <extremeprogramming@egroups.com>
Sent: Sunday, July 02, 2000 7:36 PM
Subject: Re: [XP] Re: Data Collection


> ----- Original Message -----
>
> > At 01:48 PM 7/2/00 +0000, Mark Wilden wrote:
> > >My own solution would be not to create user stories, but to maintain
the
> > >integrity and completeness of the data in the beginning (when there
isn't
> > >too much of it) and get rid of what turns out not to be needed later.
> >
> > And who's paying for this?  The customer has already told you "I Don't
> Want It!".
>
> Woah, woah, woah. :) Who said the customer said he didn't want it?
>
> He can't say yes or no unless you suggest it. You can't suggest
everything,
> and YAGNI would say don't suggest collecting data that isn't needed.
>
>
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>
>



________________________________________________________________________
________________________________________________________________________

Message: 17
    Date: Sun, 02 Jul 2000 20:02:59 -0400
    From: Ron Jeffries <ronjeffries@...>
Subject: Re: Re: Data Collection

At 04:36 PM 7/2/2000 -0700, Mark Wilden wrote:
>He can't say yes or no unless you suggest it. You can't suggest everything,
>and YAGNI would say don't suggest collecting data that isn't needed.

YAGNI is about doing, not about suggesting.  Specifically, YAGNI says
"don't put code in the system that you don't need to do today's stories".

If anyone on the project has an idea that might be a good one, the
Communication value says they should communicate it. And the customers
decide what will be done.

Ron Jeffries
www.XProgramming.com


________________________________________________________________________
________________________________________________________________________

Message: 18
    Date: Sun, 02 Jul 2000 20:09:54 -0400
    From: Ron Jeffries <ronjeffries@...>
Subject: Re: Re: Data Collection

At 07:50 PM 7/2/2000 -0400, Keith Paton wrote:
>If we are really interested in finger pointing,
>who was to blame
>
>1 the analyst who didn't mention that the program might fail in 2000?
>or
>2 the customer who didn't insist on year 2000 compliant stuff?
>
>or is there another culprit?

If the programmer thought of it and didn't mention it, he violated the
communication value.
If the customer knew about it and didn't schedule the story, he may have
made a mistake.

Being prepared to lay the blame is not part of XP. Communication is,
customer making product choices is. We're human, we'll make mistakes.

The cause of the Y2K problem, by the way, was in violating the Once and
Only Once rule, and in not having enough tests. But who knew? The book
wasn't out yet.

Ron Jeffries
www.XProgramming.com


________________________________________________________________________
________________________________________________________________________

Message: 19
    Date: Sun, 2 Jul 2000 20:50:45 -0400
    From: "Keith Paton" <paton@...>
Subject: finger pointing vs learning from our mistakes

I agree - finger pointing and blame are perhaps a poor choice of words

However when we learn from past mistakes we traditionally use the form of
words

it was because of X that Y happened

and the step from here to the notion of blaming X for Y is but a short one.

Keith
----- Original Message -----
From: "Ron Jeffries" <ronjeffries@...>
To: <extremeprogramming@egroups.com>
Sent: Sunday, July 02, 2000 8:09 PM
Subject: Re: [XP] Re: Data Collection


> At 07:50 PM 7/2/2000 -0400, Keith Paton wrote:
> >If we are really interested in finger pointing,
> >who was to blame
> >
> >1 the analyst who didn't mention that the program might fail in 2000?
> >or
> >2 the customer who didn't insist on year 2000 compliant stuff?
> >
> >or is there another culprit?
>
> If the programmer thought of it and didn't mention it, he violated the
> communication value.
> If the customer knew about it and didn't schedule the story, he may have
> made a mistake.
>
> Being prepared to lay the blame is not part of XP. Communication is,
> customer making product choices is. We're human, we'll make mistakes.
>
> The cause of the Y2K problem, by the way, was in violating the Once and
> Only Once rule, and in not having enough tests. But who knew? The book
> wasn't out yet.
>
> Ron Jeffries
> www.XProgramming.com
>
>
>
> To Post a message, send it to:   extremeprogramming@eGroups.com
>
> To Unsubscribe, send a blank message to:
extremeprogramming-unsubscribe@eGroups.com
>
> Ad-free courtesy of objectmentor.com
>
>



________________________________________________________________________
________________________________________________________________________

Message: 20
    Date: Sun, 02 Jul 2000 21:01:33 -0400
    From: Ron Jeffries <ronjeffries@...>
Subject: Re: finger pointing vs learning from our mistakes

At 08:50 PM 7/2/2000 -0400, Keith Paton wrote:
>I agree - finger pointing and blame are perhaps a poor choice of words
>However when we learn from past mistakes we traditionally use the form of
>words
>it was because of X that Y happened
>and the step from here to the notion of blaming X for Y is but a short one.

Yes. As someone who always sees a way to do better - and who can't seem to
resist making the suggestion - I find that people often hear personal blame
when I'm just talking about the code, what could make it better, what could
test it better.

Our behavior produces our results. For better results, it seems to me that
we need better behavior. But often, it seems we'd rather not know. <sigh>



Ron Jeffries
www.XProgramming.com


________________________________________________________________________
________________________________________________________________________

Message: 21
    Date: Mon, 03 Jul 2000 01:21:27 -0000
    From: "Tom Bragg" <tbragg@...>
Subject: Re: Writing Tests First for GUI Programs

Miroslav,

Thanks, that was exactly the kind of feedback I was looking for.
It's great to know you guys are here...

-Tom

--- In extremeprogramming@egroups.com, Miroslav Novak <mnovak@e...>
wrote:
> Check out
>
> http://users.vnet.net/wwake/xp/xp0001/index.shtml
>
> This article by William Wake  on testing GUI's received hearty
praise when
> first revealed to the XP community on Wiki.
>
> Miroslav Novak BSc
> Programmer/Analyst
> efaSEMS
> Capital Markets Automation
>
> Suite 800, 605 5th Avenue SW
> Calgary, Alberta, Canada  T2P 3H5
> Direct:            +1(403)294-3005
> Switchboard:   +1(403)265-6131
> Fax:               +1(403)269-7711
> Mailto:mnovak@e...
> www.efasoftware.com
>
>
>
> > -----Original Message-----
> > From: tbragg@a... [mailto:tbragg@a...]
> > Sent: Sunday, July 02, 2000 11:42 AM
> > To: extremeprogramming@egroups.com
> > Subject: [XP] Writing Tests First for GUI Programs
> >
> >
> > I'm reading XP Explained and am intrigued with the XP concept
> > (software developer for the past 30 years or so, now leading a
team
> > doing an e-commerce web site rollout).
> >
> > I'm puzzled by the "write the test first" approach as it relates
to
> > GUI software functionality (classes, etc. are clear).  Kent Beck
> > seems to say it isn't worth building automated tests for GUIs
because
> > they're brittle, etc.  If so, how do you get to 100% automated
> > testing for "only the things you care about working"?  Obviously
we
> > do care that the GUI works!  I did some surfing around but didn't
see
> > this topic addressed...
> >
> > XP should work in any language, so think about writing a VB
program.
> > Traditional approach is, prototype the UI in VB, get customer
> > acceptance, implement, test.  How do you get to testing earlier,
> > particularly in a language like VB where the graphical stuff is
so
> > dominant?  Who writes the test, is it automated and if so, how?
> >
> > All feedback welcome, thanks!
> >
> >
> >
> >
> > To Post a message, send it to:   extremeprogramming@e...
> >
> > To Unsubscribe, send a blank message to:
> > extremeprogramming-unsubscribe@e...
> >
> > Ad-free courtesy of objectmentor.com
> >



________________________________________________________________________
________________________________________________________________________

Message: 22
    Date: Mon, 03 Jul 2000 01:25:37 -0000
    From: "Tom Bragg" <tbragg@...>
Subject: Re: Writing Tests First for GUI Programs

Well... sure, "traditional approach" is waterfall in this case.

Thanks, there is a lot to think about in what you wrote... and you're
right, that's exactly how most VB programming is done.   ;-)

--- In extremeprogramming@egroups.com, "Phlip" <phlip@p...> wrote:
> From: <tbragg@a...>
>
> > XP should work in any language, so think about writing a VB
program.
> > Traditional approach is, prototype the UI in VB, get customer
> > acceptance, implement, test.  How do you get to testing earlier,
> > particularly in a language like VB where the graphical stuff is so
> > dominant?  Who writes the test, is it automated and if so, how?
>
> WaterFall rears its ugly head in many ways. Look at what you wrote:
Define
> the UI, get it accepted, write all the code behind it, test that
code. You
> might as well say your first step is to "deliver an analysis
document".
> Classic WaterFall is "analyze, design, implement, test".
>
> Snowing the customer - with either a quicky stage-prop UI, or a
bunch of
> technobabble in an "analysis document" - is fun for short-term
gains, but
> your crows will not come home to roost enough for you.
>
> Specifically, the bane of all VB-style writing is the Drill-Down
approach to
> adding code. You paint a screen, guessing at every control you'l
need, then
> you go in and write callback code under each control wiring them all
> together. This makes it easier to accidentally scatter your
business logic
> all over the place.
>
> The best way to do it is to iterate your customer acceptance with
real
> features. Take the time you would have spent painting controls, and
spend it
> implementing a single, real, target feature. Write its test code
_first_,
> then give it a simple UI: A window with a single button saying "do
it". If
> the user expresses curiosity about a real UI, draw a quick picture
of it
> with an art program. If the user expresses curiosity about the next
feature
> after this first one, you have customer acceptance.
>
> > I'm puzzled by the "write the test first" approach as it relates
to
> > GUI software functionality (classes, etc. are clear).
>
> UI controls aren't classes?
>
> > Kent Beck
> > seems to say it isn't worth building automated tests for GUIs
because
> > they're brittle, etc.  If so, how do you get to 100% automated
> > testing for "only the things you care about working"?  Obviously
we
> > do care that the GUI works!  I did some surfing around but didn't
see
> > this topic addressed...
>
> The Best of Both Worlds: All our UI toolkits have been built using
> test-first principles. This leaves in just enough hooks for our
test rigs to
> inspect windows as easily as they inspect object members.
>
> Barring that, test things which are likely to break. Don't test
getters and
> setters. If all your UI callback functions are short, they qualify
as data
> transport functions with very low likelyhood to break.
>
> Further, test things which are likely to break _obscurely_, with no
obvious
> symptoms right away. How many times (in VB land) have we said, "Oh,
don't
> worry about that bug - it's a display bug". We mean it's in the UI
code, not
> deeper down. If it's easy to spot when inspecting the UI, the risk
we'l ship
> this bug is lower.
>
> Put all those rules together, and in practice most folks just skip
the UI
> and only always automatically test everything else. That's bad
advice, but I
> follow it too ;-)
>
>  Phlip
> ======= http://users.deltanet.com/~tegan/home.html =======



________________________________________________________________________
________________________________________________________________________

Message: 23
    Date: Sun, 2 Jul 2000 18:54:15 -0700
    From: "Phlip" <phlip@...>
Subject: Re: Re: Writing Tests First for GUI Programs

From: Tom Bragg


> ...and you're
> right, that's exactly how most VB programming is done.

But _I've_ certainly never done it that way!

8-)

  Phlip
======= http://users.deltanet.com/~tegan/home.html =======




________________________________________________________________________
________________________________________________________________________

Message: 24
    Date: Mon, 03 Jul 2000 04:07:15 +0200
    From: Frank Westphal <westphal@...>
Subject: German translation of "XP Explained"

The editor of Addison Wesley in Germany sent me the
translation of "XP Explained", and I must admit
I'm not pleased with what the translator did to the
original XP vocabulary.

I'd ask any german-speaking folks on this list to
have a look at the vocabulary and make suggestions
for further improvement.

The discussion is going on over on the xp-forum:

   http://www.egroups.com/message/xp-forum/731?&start=731
   mailto:xp-forum@egroups.com

Frank


________________________________________________________________________
________________________________________________________________________

Message: 25
    Date: Mon, 03 Jul 2000 02:48:38 -0000
    From: "Jason Yip" <j.c.yip@...>
Subject: Using Different Communication Media in Requirements Negotiation

Way behind in my reading so I've only recently been going through the
May/June 2000 issue of IEEE Software.

I thought the article "Using Different Communication Media in
Requirements Negotiation" was interesting.  For one thing, I was
actually one of the students that participated and another thing, she
found that a particular distributed communication setting (faciliator
and customer 1 on one site, system analyst and customer 2 on the
other site) was more effective than face-to-face.  One proposed
explanation is that separating the customer with conflicting
interests allowed for less emotional negotiation (I'm reminded
suddenly of a User Friendly story line...).

I was wondering if anyone had any comments on this, especially
Alistair.

As a side note, I played the role of system analyst on the D1 setup
which apparently turned out to be the best one.  I'm sure that my mad
negotiation skillz didn't skew the results too much though... :-)



________________________________________________________________________
________________________________________________________________________