Re: A simple unit test framework
On May 7, 10:20 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On May 6, 9:46 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On May 6, 3:31 am, Ian Collins <ian-n...@hotmail.com> wrote:
Gianni Mariani wrote:
I have met very few customers that know what a spec is even if it
smacked them up the side of the head.
Welcome to the club!
Sad. Inevitably it leads to pissed off customer.
Any agile process (XP, Scrum or whatever) is ideal for this situatio=
n.
If your goal is to rip off the customer, yes.
[First, a meta-comment: I am, of course, exagerating to make
a point, and I don't really suspect Ian of trying to use any
technique to rip off his customers.]
So by helping them to get what they really wanted, rather than forcing
them to commit to what they thought the wanted, I'm ripping them off?
How does testing help the customer to get what he really wants?
By being an integral part of the process.
Testing is, and always has been, an integral part of the
process. Just as is design, coding, code review, integration...
Obviously, having a process does help the customer get what he
wants. My question was more along the lines of: how does
involving the customer in all this (most of which he doesn't
care about, nor understand) help him get what he wants?
Roughly speaking, the user interface needs prototyping; the rest
of the code needs specification. But I don't really see a role
for testing.
Not every customer is in a position to provide specifications and those
that think they can often change their minds once the development has
started.
You need some sort of specification to begin coding. If the
customer can't provide it, you provide it for him, but you do
get him to sign it off.
And of course, specifications have never been cast in stone.
They evolve. But it's not open ended, either. If the customer
suddenly decides that he wants the program to do ten times more
than was originally considered, that will have an impact on the
cost and the delay. The customer asks for the change, I work
out how much it will cost, in time and money, and he decides
whether he wants it or not.
I've seen companies who never accepted any changes. They very
soon find themselves without any customers. I've also seen
companies who accepted all changes, without consideration of the
additional time or cost. They very soon go bankrupt. It's a
two way street.
But I'm sure you know all this. What I want to know is what
relationship this has to testing, per se? These have been
self-evident truths since my first contact with computer
science, back in the 1960's.
The person I'm ripping off is me, I'm doing my self out of all the bug
fixing and rework jobs.
Man you have a strange view of customer focused development.
Customer focused means talking to the customer in his language,
not in yours. A test suite doesn't do this. Getting a customer
to sign off a project on the basis of a test that he's not
capable of understanding is not, IMHO, showing him much respect.
If you were to take the time to look into XP or Scrum, you would see
that you are to some extent preaching to the choir.
I wonder if part of our differences don't have to do with the
type of applications we write. In another posting, you
mentionned that you did a program for a Web. In other words,
most of your requirements are visible behavior, and the
requirements for reliability and longivity aren't really very
high. I'm not too sure what you understand by "tests" here,
because I consider unit tests something that runs automatically,
with no visible output unless there is an error, but certainly,
in such a context, showing the customer a more or less working
program very early in the process, and getting feed back from
it, is important.
I work mainly on large scale servers. The programs run 24 hours
a day, 7 days a week. Deploying a new version may mean stopping
the system, at considerable cost. Nothing that the program does
is immediately visible (but if it doesn't work, a lot of other
things suddenly stop working, and that IS visible). An error in
the code costs real money.
That's why there are (web driven) test suites like FIT or
Selenium that are specifically designed for the customer to
understand and in some cases, use them selves. Don't forget
the customer acceptance tests are system behavioral tests, not
code unit tests (unplug module A and module A missing trap is
sent kind of tests). How the application behaves is what the
customer wants to see.
Or doesn't want to see:-). (Much of my work in the past has
been involved with network routing. Which normally should
happen silently, behind the scenes.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34