Another interesting conversation with Tom Brown.



Tom Brown writes:

>

> (acceptance-testing.html)

>

>    Grow the test language classes with YAGNI in mind. Let the customer

>    drive the growth.

>

> ?? YAGNI? never heard of it.



You aren't going to need it.  It's an XP term.  I've got a glossary

with these terms.  I'm probably going to expand more abbrevs.



>

>       sub search_for {

>           my($self, $what) = @_;

>           my($uri) = 'http://localhost:8888/pub/search?search='

>               .URI::Escape::uri_escape($what);

>           my($hresp) = LWP::UserAgent->new->request(

>               HTTP::Request->new(GET => $uri),

>           );

>           die($uri, ': request failed: ', $hresp->status_line)

>               unless $hresp->is_success;

>           return;

>       }

>

>    <snip>

>    The result is an HTTP::Response, which encapsulates ...

>

> huh? I'd think the result is $hresp->is_success

>

>    also:

>

>       sub expect_text {

>

> grabs a $self->get('hresp'); object that wasn't cached in

> search_for() ... you don't seem to have subclassed anything, so

>

> oh, that's the next paragraph, ok. But that probably fixes your

> return value problem, so search_for() as shown is probably wrong.



The acceptance-testing chapter is not tested.  I should have mentioned

this, sorry.  The infrastructure we have needs to be repackaged to

support the cleaner form in the book.  It's not much work, but....



> Who is your target audience? I probably jumped into the middle (

> acceptance-testing.html), but I'm finding it a heavy going. For

> me that is a good thing, it means everything is relevent and has

> to be read carefully, but it might blow others away (I've read

> most of the XP Series, coded in PERL for many years, and been

> coach and client to an XP team for 8 months).



There will be an intro.  Here's the list of chapters:



Chapter 1: Introduction

Chapter 2: What's the story?

Chapter 3: Look who's talkin'?

Chapter 4: Coding Style

Chapter 5: Unit Testing

Chapter 6: Refactoring

Chapter 7: Acceptance Testing

Chapter 8: Declarative Programming

Chapter 9: Databases



I am writing to an advanced audience.  To me, XPL is not for junior

programmers picking up a book and reading about it.  It takes a lot of

sophistication to understand OO, customer-developer relationships, and

testing.  There are a gadzillion perl shops out there with senior

people who just haven't been exposed to some of the ideas such as

declarative programming, but can easily understand them.



> yieah...

>

>    return &{\&{'_inc_'.lc($self->get_name)}}($date_time);

>

> is an "improved" syntax?



Yes. :)  It embodies once and only once.  You have to stare at it, but

it guarantees a number of good things:



    * dies if there is no implementation without having extra code

      to say the same thing.

    * dispatches correctly without chance of cut-and-paste errors.

    * doesn't use temporary variables.

    * is declarative



One thing that is special about Perl is that you don't have to have

lookup tables, which are prone to error.  The interpreter has a

perfectly good lookup table, which is made available to you.  If you

don't take advantage of it, you are not abiding by the once and only

once philosophy.



If the team can understand the code, it should be used.  It's not an

esoteric practice in the Lisp community.  If it is good enough for

them, why shouldn't we use it?



Now the *syntax* is damn ugly.  I can't help that.  Perl is

syntax-heavy.  It's like adding a negative lookbehind to an regular

expression.



> I prefered the longer one (refactoring.html).

> [ok, looking back on that, you're just creating a subroutine name and

> running it.. but it took me a while to figure that out...] I wrote some

> nicely structured code in one of my early co-op workterms. Looking back,

> it _must_ have been completely rewritten. It packed data elements into

> appropriately sized spaces in a data communications packet. Unfortunately,

> looking back, my command of C was probably _much_ better than the average

> student programmer to follow me, and expecting them to understand

> extracting packet sizes out of bitmaps, and keep the client and server

> maps synchronized was probably unrealistic. Almost certainly a case of

> "optimize later", but I remember it more strongly as code that must have

> been either rewritten or removed because no one following me would

> _understand_ it.



XP solves this problem with pair programming.  There are four eyes on

every line of code in theory.  This isn't the case at bivio, but

that's ok, too.  We share a very common understanding of how we code.

It's tough to tell who wrote what code.



> (Keep in mind that the guy that wrote the client side of things copied

> values all over the place, allowed the user to change one of them, and

> then picked one to copy back to the 'server' ... He obviously didn't know

> what pointers were, and I'm not sure if he ever realized that if he copied

> the value 5 times, then there were four "update" links in his GUI that

> didn't work...)

>

> nitpick: you're a heavy user of int() where I would use

>    scalar() or nothing. I keep looking for the roundoff, and

>    end up realizing you're just changing the context



I use int() with arrays.  This seems the right place for it.  scalar

doesn't place a type on the value, i.e.



     $second_arg = 35 if int(@_) < 3;



> I like the change from un-named to named parameters refactor



Thanks.



> I was about to ask you about "Analyzing Coverage" ... our senior

> programmer was curious, thanks for the tip...



It's ok.  A bit hard to decipher in practice, I feel.  We don't use it

on any regular basis.  In XP, you're supposed to test first, by

intention, so coverage is impossible.  I don't do this very often, but

you get the idea.



Rob

> I am writing to an advanced audience.  To me, XPL is not for junior

> programmers picking up a book and reading about it.  It takes a lot of

> sophistication to understand OO, customer-developer relationships, and

> testing.  There are a gadzillion perl shops out there with senior

> people who just haven't been exposed to some of the ideas such as

> declarative programming, but can easily understand them.







Does the book only refer to bOP examples?



It then would be like "Instant CGI/Perl" which relates to the Extropia

web application framework.



I would like to see also other examples that use the Perl Test::*

modules. Or some of the GUI testing modules mentioned in the other

mailing lists (I think it was 'Bricolage-Devel').





>>yieah...

>>

>>   return &{\&{'_inc_'.lc($self->get_name)}}($date_time);

>>

>>is an "improved" syntax?

>>

>

> Yes. :)  It embodies once and only once.  You have to stare at it, but

> it guarantees a number of good things:

>

>    * dies if there is no implementation without having extra code

>      to say the same thing.

>    * dispatches correctly without chance of cut-and-paste errors.

>    * doesn't use temporary variables.

>    * is declarative





Do you run it inside eval?

For me, a dispatch table has other advantages: You can store additional

information (like validation hooks, access privileges).

Do you think temporary variables are bad?

Why do you build a reference first and then dereference? I mean:

return &{'_inc_'.lc($self->get_name)}($date_time);

should also possible, or even

('_inc_'.lc($self->get_name))->($date_time);



I am not so experienced, maybe I don't get the point.





> I use int() with arrays.  This seems the right place for it.  scalar

> doesn't place a type on the value, i.e.

>

>     $second_arg = 35 if int(@_) < 3;





So, you only use it, because it is more descriptive?





Thank you,



good bye, Uwe

> Does the book only refer to bOP examples?



For the most part, yes.  I am not particularly happy about it.  My

goal is to sell the idea that perl is an application programming

language, and that it is ideally suited to XP style development.  When

you read Java code, you see tremendous consistency.  The style flows.

We use CPAN quite a bit, but it isn't consistent.  In particular the

OO model is used inconsistently and naming is not uniform.  In XP,

the team writes code in one voice.  If they don't, refactoring is

more difficult.



In no way do I mean that perl should be programmed in only one way.

The team needs to agree on the way, but it can be any way.



An important theme in the book is that declarative programming is the

ultimate application of the once in only once principle, and that perl

lets you program declaratively more easily than other imperative

languages, e.g. VB, Java and C++.  I just read an interesting quote:



   Programming languages teach you not to want to what they cannot

   provide.  -- Paul Graham, ANSI Common Lisp



The difference between bOP and other frameworks is that bOP tries hard

to allow you program declaratively.



> It then would be like "Instant CGI/Perl" which relates to the Extropia

> web application framework.



We released bOP not necessarily as a replacement for existing

frameworks.  Rather we released it to give our consulting group an

anchor, and provide another example of how to program perl.



I have never been afraid of writing infrastructure.  We didn't write

bOP in one day.  It evolved over time.  We had an end-to-end

implementation running for our mail service within a month.  The

architecture has gone through many major revisions.  For example, we

just changed the basic object type from a hash_ref to an array_ref.



> I would like to see also other examples that use the Perl Test::*

> modules. Or some of the GUI testing modules mentioned in the other

> mailing lists (I think it was 'Bricolage-Devel').



I try to steer clear of stuff I don't know.  I am not a GUI

programmer, and I have very little experience testing GUIs.  I talked

about it a little bit, and included some references because it is an

important topic.



Another goal of the book is to keep it under 300 pages. I isn't a

cookbook, or perl reference book.  XPL is not revolutionary, it builds

on a lot of existing material.



> Do you run it inside eval?



No.



> For me, a dispatch table has other advantages: You can store additional

> information (like validation hooks, access privileges).



YAGNI.  In this particular case, the dispatch table would have added

more code, violated the once and only once principle, and probably be

slower.



> Do you think temporary variables are bad?



Yes, unless you need them to save an expensive operation (no rules

here).  Temporary variables are state, and reliability is improved

when all you have to deal with is stateless algorithms.



One of the frustrations of functional programmers is that their

systems are unpopular.  To me, this is throwing out the baby with the

bath water.  There are a lot of great concepts in functional and

declarative programming, which are obscured by their practitioners.

Try to find a nonmathematical explanation of declarative programming.

Most programmers are not mathematicians in the formal sense, and

descriptions of the power of declarative programming are usually

written for mathematicians.  With the advent of XML, we are starting

to see a change.  Unfortunately, XML is a purely declarative language,

and it suffers as a result.  You can't program anything XML so now you

need two languages at least to actually do something.



In perl you can program imperatively, and create cool declarative

interpreters.  This allows you to create large applications with very

little code, which is understandable by only knowing one language.



> Why do you build a reference first and then dereference? I mean:

> return &{'_inc_'.lc($self->get_name)}($date_time);

> should also possible, or even

> ('_inc_'.lc($self->get_name))->($date_time);



We always use strict and -w.  This requires you to build referenceduring,

and then dereference it.



>

> > I use int() with arrays.  This seems the right place for it.  scalar

> > doesn't place a type on the value, i.e.

> >

> >     $second_arg = 35 if int(@_) < 3;

>

>

> So, you only use it, because it is more descriptive?



I guess so. perhaps all of the examples I have seen used int() on

arrays.  It seems intuitive to me as well.



Cheers,

Robthe

> > >

> > >     $second_arg = 35 if int(@_) < 3;

> >

> >

> > So, you only use it, because it is more descriptive?

>

> I guess so. perhaps all of the examples I have seen used int() on

> arrays.  It seems intuitive to me as well.



but it's not. An array in a scalar context is the number of elements in

it. I don't need to tell you that, your knowledge of the language is

better than mine....



adding the int() function makes me look at _why_ you are adding the

function, and try to find the twist that needs it. There isn't one, so

I've wasted time figuring that out. That is why I prefer either scalar()

or nothing.



Obviously, it's mostly a matter of style. Does it matter? I can't answer

that. For the book to be used/popular you probably want to try to code to

your target audience. No individual can claim to represent that.



-Tom

Tom Brown writes:

> but it's not. An array in a scalar context is the number of elements in

> it. I don't need to tell you that, your knowledge of the language is

> better than mine....



I'm not so sure about that.



> adding the int() function makes me look at _why_ you are adding the

> function, and try to find the twist that needs it. There isn't one, so

> I've wasted time figuring that out. That is why I prefer either scalar()

> or nothing.



Nothing like data to backup a hypothesis:



trgrep '\bint\(?\s*@' /usr/lib/perl | grep -v Bivio | wc

6



trgrep '\bscalar\(?\s*@' /usr/lib/perl | grep -v Bivio | wc

157



The scalars have it.  I'll change it to be nothing or scalar where

required, thanks.



> Obviously, it's mostly a matter of style. Does it matter? I can't answer

> that. For the book to be used/popular you probably want to try to code to

> your target audience. No individual can claim to represent that.



This is the danger of writing a book about perl and XP.  Whenever I

mention that I program in perl at an XP meeting, I get the strangest

looks.  Fortunately, the perl community is more forgiving about XP.

Yet they aren't the easiest audience to please either.  :)



Cheers,

Rob

On Tuesday 29 January 2002 13:15, you wrote:



> This is the danger of writing a book about perl and XP.  Whenever I

> mention that I program in perl at an XP meeting, I get the strangest

> looks.  Fortunately, the perl community is more forgiving about XP.

> Yet they aren't the easiest audience to please either.  :)



I've had fairly good results combining the two.  It's convincing free

software folks to write tests that's tricky.



-- chromatic

Hi Rob,



On Tue, 29 Jan 2002, Rob Nagler wrote:



> I am not a GUI programmer, and I have very little experience testing GUIs.



I spent the better part of the previous two years doing both, for a

system with something approaching 4 million users world-wide (IE and

Netscape, versions 4+ only).  If there's anything you want to ask, do

please ask.  I won't know the answer.



73,

Ged.

On Tue, 29 Jan 2002, chromatic wrote:

> On Tuesday 29 January 2002 13:15, you wrote:

>

>> This is the danger of writing a book about perl and XP.  Whenever I

>> mention that I program in perl at an XP meeting, I get the strangest

>> looks.  Fortunately, the perl community is more forgiving about XP.

>> Yet they aren't the easiest audience to please either.  :)

>

> I've had fairly good results combining the two.  It's convincing free

> software folks to write tests that's tricky.



Correction: it's convincing *anybody* to write tests when they haven't

learned to on their own that's tricky.



I've also noticed it's rather difficult to get a lot of XPers to

understand you can do it outside their chosen language.  Except that I

have seen some Java XPers that seemed to understand you can do it in

SmallTalk.



Ed

Well, as a new convert to writing tests I can attest to your

hypothesis. In general I have not sat down and written a good test

suite when coding something new. But I did so with a new module I

just wrote and I'm sold on the utility of tests.



Case in point. I wanted to make getting config vars case insensitive.

So I saved everything as lowercase hash keys. But this broke

something else, so I had to go back. Because I had tests, it was very

easy to see when everything was working correctly again. This benefit

alone is what really sold me on tests.



How to convince people to wite tests? Chromatic's article on perl.com

was excellent in showing HOW to write tests. Perhaps we need an short

article showing exactly how tests made a project easier? Heck, I've

got time, maybe I'll put something together...



Drew



--- In extremeperl@y..., chromatic <chromatic@r...> wrote:



> I've had fairly good results combining the two.  It's convincing

free

> software folks to write tests that's tricky.

>

> -- chromatic

On Tuesday 05 February 2002 16:50, drewbie74 wrote:



> How to convince people to wite tests? Chromatic's article on perl.com

> was excellent in showing HOW to write tests. Perhaps we need an short

> article showing exactly how tests made a project easier? Heck, I've

> got time, maybe I'll put something together...



How about some brainstorming then?  Here are several benefits of writing

tests, in no particular order:



  - to clarify the intent of the code

  - to enforce behavioral compatibility

  - to explore boundary conditions

  - to ensure that bugs have been corrected

  - to ensure that bugs remain corrected

  - to exercise an interface

  - to help with decoupling (when writing code for testability)

  - to add explanations of behavior (when using good test names with

Test::More)



There's obviously more (to make refactoring possible), but there's a

disturbing tendency to rewrite software from scratch, and I'm picking my

battles for now.



-- c

At 11:49 AM 2/6/2002 -0800, chromatic wrote:



>On Tuesday 05 February 2002 16:50, drewbie74 wrote:

>

> > How to convince people to wite tests? Chromatic's article on perl.com

> > was excellent in showing HOW to write tests. Perhaps we need an short

> > article showing exactly how tests made a project easier? Heck, I've

> > got time, maybe I'll put something together...

>

>How about some brainstorming then?  Here are several benefits of writing

>tests, in no particular order:

>

>  - to clarify the intent of the code

>  - to enforce behavioral compatibility

>  - to explore boundary conditions

>  - to ensure that bugs have been corrected

>  - to ensure that bugs remain corrected

>  - to exercise an interface

>  - to help with decoupling (when writing code for testability)

>  - to add explanations of behavior (when using good test names with

>Test::More)

>

>There's obviously more (to make refactoring possible), but there's a

>disturbing tendency to rewrite software from scratch, and I'm picking my

>battles for now.

>

>-- c



Well, based on some work I did last night I have a prime example. I had

written some modules previously that worked and are currently in

production. Since there were no tests for said modules, I begun witing them

last night using Test::More (Thank you SO much Schwern - it rocks!). In the

process of doing so, I ended up doing some refactoring to make the modules

more flexible and worked out a couple of possible bugs. In the end, I had

better, more flexible, and refactored code that had good,comprehensive

tests - fulfilling the last 5 items in your list above. I was also forced

to setup a development environment (including a db) that had test data and

which I could use for testing purposes in perpetuity. This alone was worth

it's weight in gold.



For me, the acts of refactoring and writing tests now go hand in hand. Yes,

it takes time, sometimes a lot. But it is time well spent because it makes

your code better by the very nature of writing tests & making sure they

correctly run. It's hard to do one without the other because it's difficult

to make sure your "enhancement" isn't really a bug.



To address your last point, having tests helps keep me from rewriting code.

The tests help keep me from rewriting because I can fix only what is broken

or needs enhancing rather than thinking "This code is a bunch of crap!

Let's throw it out and just start over." Starting over is likely to

introduce more bugs than you fix. And this of course is exactly what you

were trying to avoid in the first place.



Oh geez, I hope I'm not becoming a zealot. Not that it would be a bad thing...





Well, based on some work I did last night I have a prime example. I had

written some modules previously that worked and are currently in

production. Since there were no tests for said modules, I begun witing them

last night using Test::More (Thank you SO much Schwern - it rocks!). In the

process of doing so, I ended up doing some refactoring to make the modules

more flexible and worked out a couple of possible bugs. In the end, I had

better, more flexible, and refactored code that had good,comprehensive

tests - fulfilling the last 5 items in your list above. I was also forced

to setup a development environment (including a db) that had test data and

which I could use for testing purposes in perpetuity. This alone was worth

it's weight in gold.



For me, the acts of refactoring and writing tests now go hand in hand. Yes,

it takes time, sometimes a lot. But it is time well spent because it makes

your code better by the very nature of writing tests & making sure they

correctly run. It's hard to do one without the other because it's difficult

to make sure your "enhancement" isn't really a bug.



To address your last point, having tests helps keep me from rewriting code.

The tests help keep me from rewriting because I can fix only what is broken

or needs enhancing rather than thinking "This code is a bunch of crap!

Let's throw it out and just start over." Starting over is likely to

introduce more bugs than you fix. And this of course is exactly what you

were trying to avoid in the first place.



Oh geez, I hope I'm not becoming a zealot. Not that it would be a bad thing...



Drew Taylor                     JA[P|m_p|SQL]H

http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker

mailto:drew@...      *** God bless America! ***

Drew Taylor writes:

> At 11:49 AM 2/6/2002 -0800, chromatic wrote:

> >How about some brainstorming then?  Here are several benefits of writing

> >tests, in no particular order:



I like to distinguish between acceptance and unit tests.  For unit

tests, I would add:



- to validate the API

- to enable refactoring

- to keep the cost of change constant



A unit test suite is like a semantic compiler.  In dynamic languages,

like Perl, there needs to be something to validate the code.



For acceptance tests, I would add:



- to encode concisely the domain knowledge of the customer

- to help the development team understand the problem



> Oh geez, I hope I'm not becoming a zealot. Not that it would be a bad thing...



Praise the Tests brother!



Rob

Could you explain a little more about the two types of tests you mention

below? Specifically the acceptance tests, and how they would relate to web

apps. I'm trying to become more of an "architect", so a lot of the "domain

knowledge" stuff you & other texts mention is still a little fuzzy to me. I

read some of the docs on bivio, and it sounded very interesting.

Unfortunately more of it than I wanted was over my head. I'm very intrigued

about the platform you released and how to learn more about it in the

future - it would be a great learning tool for me.



It sounds like the tests I wrote last night would be unit tests as they

test object instantiation & the APIs.



Drew



At 03:35 PM 2/6/2002 -0700, Rob Nagler wrote:



>I like to distinguish between acceptance and unit tests.  For unit

>tests, I would add:

>

>- to validate the API

>- to enable refactoring

>- to keep the cost of change constant

>

>A unit test suite is like a semantic compiler.  In dynamic languages,

>like Perl, there needs to be something to validate the code.

>

>For acceptance tests, I would add:

>

>- to encode concisely the domain knowledge of the customer

>- to help the development team understand the problem



Drew Taylor                     JA[P|m_p|SQL]H

http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker

mailto:drew@...      *** God bless America! ***

Drew Taylor writes:

> Could you explain a little more about the two types of tests you mention

> below?



There are many different kinds of tests including performance and load

testing.  In XP we're mostly concerned about unit and acceptance

testing.



> Specifically the acceptance tests, and how they would relate to web

> apps.



What is beautiful about the Web is that HTTP and HTML are a messaging

interface.  You can build a complete acceptance test suite without

dealing with GUI scripting.



An acceptance test is a way of verifying end-user functions.  A unit

test verifies programmer level functions.  Both can test Web software.



> I'm trying to become more of an "architect",



Before you do, read this article:



http://joel.editthispage.com/stories/storyReader$320



One of the things I'm trying to learn is to become less of an architect.



> so a lot of the "domain

> knowledge" stuff you & other texts mention is still a little fuzzy

> to me.



Domain knowledge is simply "the problem".  What I like about XP is

that it is problem-oriented, not solution-oriented.



> I

> read some of the docs on bivio, and it sounded very interesting.

> Unfortunately more of it than I wanted was over my head. I'm very intrigued

> about the platform you released and how to learn more about it in the

> future - it would be a great learning tool for me.



The great thing about perl is that lots of people have created lots of

code.  We put out bOP, because it has no intrinsic value as a

product.  There are just too many good toolkits out there.  I consider

this a testament to perl more than anything else.  You can create

incredibly solid software very quickly.



> It sounds like the tests I wrote last night would be unit tests as they

> test object instantiation & the APIs.



Yes, it sounds like you wrote unit tests.  They are incredibly

important tools.  We're slowly creating unit tests for our code.  It's

tough to do, but we regret it every time we make changes and there is

no test to validate that we haven't broken anything.



Hope this helps.



Rob

At 10:52 PM 2/6/2002 -0700, Rob Nagler wrote:

>Drew Taylor writes:

> > Specifically the acceptance tests, and how they would relate to web

> > apps.

>

>What is beautiful about the Web is that HTTP and HTML are a messaging

>interface.  You can build a complete acceptance test suite without

>dealing with GUI scripting.

>An acceptance test is a way of verifying end-user functions.  A unit

>test verifies programmer level functions.  Both can test Web software.



How do you do that? I've only heard of tools that allow you to create a

script and then playback that script. This is semiuseful, but what happens

if you make a change to the interface? What tools/techniques have you used

in the past to do acceptance testing? Do I have to setup a fake web server

environment & run the tests that way? That wouldn't be too difficult in a

CGI environment, and there are things like Apache::Fake now.



> > I'm trying to become more of an "architect",

>

>Before you do, read this article:

>

>http://joel.editthispage.com/stories/storyReader$320

>

>One of the things I'm trying to learn is to become less of an architect.



I hadn't seen that one before, although I have read some of Joel's other

articles. I'll read it tomorrow morning. My brief look says it will be

good. What I'm ultimately interested in learning is better design. Learning

patterns is one step, and working to see the problem from a higher level

view are two things I'm doing now.



> > so a lot of the "domain

> > knowledge" stuff you & other texts mention is still a little fuzzy

> > to me.

>

>Domain knowledge is simply "the problem".  What I like about XP is

>that it is problem-oriented, not solution-oriented.



OK. Why don't they just say that? :-) I know that at high levels it's

essential that we're all speaking the same language, but can't that

language be simpler?



> > I

> > read some of the docs on bivio, and it sounded very interesting.

> > Unfortunately more of it than I wanted was over my head. I'm very

> intrigued

> > about the platform you released and how to learn more about it in the

> > future - it would be a great learning tool for me.

>

>The great thing about perl is that lots of people have created lots of

>code.  We put out bOP, because it has no intrinsic value as a

>product.  There are just too many good toolkits out there.  I consider

>this a testament to perl more than anything else.  You can create

>incredibly solid software very quickly.



This ability to quickly create a great product is one of the things that

really attracted me once I got serious about perl. I've seen several

frameworks that have interested me, including OpenInteract, OpenFrame, and

Mason. One day I hope I have the time to put some effort into learning each

better. I can just imagine all the tidbits of knowledge waiting to be

gleaned from each one.



> > It sounds like the tests I wrote last night would be unit tests as they

> > test object instantiation & the APIs.

>

>Yes, it sounds like you wrote unit tests.  They are incredibly

>important tools.  We're slowly creating unit tests for our code.  It's

>tough to do, but we regret it every time we make changes and there is

>no test to validate that we haven't broken anything.



Yep, they were definitely unit tests. And as I mentioned before, I'm very

grateful I've written the ones I have because they did exactly what they're

supposed to do. Tell me when bugs appear and when they've been fixed. Once

I've gotten more tests done, I need to look into Test::Harness so I can run

them all at one swoop.



To illuistrate your last point, I have an example. At a previous employer,

we had a large codebase of perl modules (I bet it's probably doubled by

now) but no tests. I'm still close friends w/ the lead QA person and she

often just tests what she can and blindly hopes everything else still

works. It's just not possible to test every facet of the code for every

release (which is every 1-2 months). I really doubt that a comprehensive

test suite will ever be written, even though I have no doubt that it would

be an extremely important tool. The CTO's not convinced of the need, and I

don't think they would have/put the time to write a comprehensive suite

anyway. Besides, they're probably a little afraid of all the little bugs it

might turn up. ;-)



Could this be a hidden reason some shops are wary of tests?



Drew

Drew Taylor                     JA[P|m_p|SQL]H

http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker

mailto:drew@...      *** God bless America! ***

On Wednesday 06 February 2002 23:33, Drew Taylor wrote:



> The CTO's not convinced of the need, and I don't think they would have/put

> the time to write a comprehensive suite anyway. Besides, they're probably a

> little afraid of all the little bugs it might turn up. ;-)



> Could this be a hidden reason some shops are wary of tests?



If it's hidden, it's not hidden very well.  :)  Here's my take.



Programmers don't want to write tests because:



  - it's not their job

  - it's not "real" coding

  - it's not as sexy as "real" coding

  - they don't know how

  - they don't know (or believe) the benefits

  - it's hard (but only the smart ones really believe this)



Managers don't want coders to write tests because:



  - it takes time away from "real" coding

  - QA should handle it

  - it's cheaper to fix bugs when they're found



I'm only sympathetic to the coders who don't yet know how and those who think

writing tests is difficult.  (I'll even propose that, unless you're adding

tests to a system that has none, it *shouldn't* be difficult.  If it is,

you're not coding for testability and you're asking for trouble.)



Okay, my analyst hat is off.  Feel free to jump on this thread with

evangelism if anyone has questions.



  * * * * *



As for your Test::Harness question, use h2xs to make a skeleton Makefile.PL

for your project.  Put your tests in the t/ subdirectory, edit the @INC paths

if needed, and run 'perl Makefile.PL; make; make test' and it should Just

Work.



Now you know just about as much as I care to remember about the whole process.



-- c

> How do you do that? I've only heard of tools that allow you to create a

> script and then playback that script. This is semiuseful, but what happens

> if you make a change to the interface?



The first step is to make sure your interface has structure.  If you

are testing arbitrarily constructed templates, you're going to have a

rough time.  If you build your HTML pages from widgets or

parameterized templates, you'll have some structure to grab on to.



> What tools/techniques have you used

> in the past to do acceptance testing?



The best tool is perl.  We used it to test our CORBA based Web server,

and we use it to test our application written in perl.  It is not very

hard to build an acceptance test suite using tools like LWP and

HTMLParser.



I am a little behind schedule.  My goal is to release our internal

infrastructure by the end of the month.  It will come with a test

suite which tests our pet shop demo (http://petshop.bivio.biz).



> Do I have to setup a fake web server

> environment & run the tests that way?



I find for acceptance testing you need a test environment which is as

close to your production environment as possible.  Any of our

developers can run the test suite on their personal Web servers.

Every night we run the test suite against our test servers, which are

relatively clean machines.



> good. What I'm ultimately interested in learning is better design. Learning

> patterns is one step, and working to see the problem from a higher level

> view are two things I'm doing now.



To me, there are two sides: analysis and synthesis.  Patterns are

about synthesis.  XP is about analysis.  I'm not a big fan of

patterns, because they're very focused on classical object-oriented

programming, and I try to program declaratively whenever I can.  In

addition, languages like Java, have some serious deficiencies such as

weak ability to delegate and no class level inheritance.



I find reading books about Lisp, functional programming, and logic

programming expands my solution set much better than reading a book

about design patterns.



> OK. Why don't they just say that? :-) I know that at high levels it's

> essential that we're all speaking the same language, but can't that

> language be simpler?



It is really hard to write cogent prose, which addresses a wide

audience.  They're just some concepts which are hard to explain in

simpler language.  I'm reading a book by Einstein which is incredibly

well written but I have a really hard time understanding his

discussions about the special theory and general theory of

relativity.  That's why I'm a programmer, I guess.



> anyway. Besides, they're probably a little afraid of all the little bugs it

> might turn up. ;-)

>

> Could this be a hidden reason some shops are wary of tests?



I don't think so.  In general, people have a hard time quantifying

quality.  If it works in the general case, it may be enough.  The user

base may be small.  I really like Gerry Weinberg's comments on quality

in his book "Quality Software Management: Vol. 1 Systems Thinking":



  The Quality Statement: Every statement about quality is a statement about some

  person(s).



  The Political Dilemma: More quality for one person may mean less

  quality for another.



  The Quality Decision: Whose opinion of quality is to count when making

  decisions?



  The Inadequate Definition of Quality: Quality is the absence of error.



  The Absence of Errors Fallacy: Though copious errors guarantees

  worthlessness, having zero errors guarantees nothing at all about the

  value of software.



I highly recommend the book.



Rob

At 11:45 PM 2/6/2002 -0700, chromatic wrote:



><snip> excellent points </snip>



>I'm only sympathetic to the coders who don't yet know how and those who think

>writing tests is difficult.  (I'll even propose that, unless you're adding

>tests to a system that has none, it *shouldn't* be difficult.  If it is,

>you're not coding for testability and you're asking for trouble.)



All your points are right on the money. I would venture to guess that most

"good" programmers would not be against writing tests. IMHO, it's usually

managements edicts & timelines that forces the lack of tests. As for the

last point, I read somewhere (perhaps in one of Steve McConnell's books)

that a study found it takes magnitudes of more time/money to fix a bug

after the fact that to fix it before. And if it negatively affects a

customer, then multiply that cost by several factors for pissed off said

customer. If only management could be made to understand this fact, getting

tests would be much simpler. If I ever get a fulltime job again, I

certainly will push for good tests, even if it's just unit tests.



I was once one of those people who didn't understand how easy it is to

write tests. Yes, it took some time to get a good test environment setup,

but it was worth the few hous it took. And now I can easily and _quickly_

add new tests. Modules like Test::Simple & Test::More are the key.



>As for your Test::Harness question, use h2xs to make a skeleton Makefile.PL

>for your project.  Put your tests in the t/ subdirectory, edit the @INC paths

>if needed, and run 'perl Makefile.PL; make; make test' and it should Just

>Work.



That's almost too easy... But then, this IS perl we're talking about. :-)



[OT] As an aside, why is it that when I do Reply TO All in Eudora that the

mailing list is on the to line twice, rather than the poster & the list?

It's rather annoying since that is my usual behavior. Or is this considered

bad form? I've never gotten a good answer on this question.



Drew

Drew Taylor                     JA[P|m_p|SQL]H

http://www.drewtaylor.com/      Just Another Perl|mod_perl|SQL Hacker

mailto:drew@...      *** God bless America! ***

Hi all,



On Thu, 7 Feb 2002, Drew Taylor wrote:



> At 11:45 PM 2/6/2002 -0700, chromatic wrote:

[snip]

> managements edicts & timelines that forces the lack of tests. As for the

> last point, I read somewhere (perhaps in one of Steve McConnell's books)

> that a study found it takes magnitudes of more time/money to fix a bug

> after the fact that to fix it before. And if it negatively affects a

> customer, then multiply that cost by several factors for pissed off said

> customer. If only management could be made to understand this fact...



See attached.



I once had to fly to seven or eight different countries over a period

of several weeks to fix a $0.25 problem in a couple of hundred $22,000

instruments because the guy in procurement had ignored my written

procurement specification and the guy in test had ignored my written

test secification.  The problems only started to surface when the

instruments were used in hot places.



It still bugs me that I didn't send a bill to their employer, who was

my supplier and contracted to make the things to the specification.



It's called experience.



73,

Ged.





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

Rob Nagler wrote:



>>What tools/techniques have you used

>>in the past to do acceptance testing?

>>

>

> The best tool is perl.  We used it to test our CORBA based Web server,

> and we use it to test our application written in perl.  It is not very

> hard to build an acceptance test suite using tools like LWP and

> HTMLParser.

>

> I am a little behind schedule.  My goal is to release our internal

> infrastructure by the end of the month.  It will come with a test

> suite which tests our pet shop demo (http://petshop.bivio.biz).

>

>

>>Do I have to setup a fake web server

>>environment & run the tests that way?

>>

>

> I find for acceptance testing you need a test environment which is as

> close to your production environment as possible.  Any of our

> developers can run the test suite on their personal Web servers.

> Every night we run the test suite against our test servers, which are

> relatively clean machines.



Since you are talking about testing apps against webserver, I'd plug in

the new Apache::Test framework which most Apache::* modules' and

frameworks' developers will find very helpful. The goal is to have every

Apache::* module needing mod_perl or just plain apache env, use

Apache::Test for its test. There is no more excuses for not having

tests. And if something is missing from its functionality now it's the

time to jump in and ask for it/add it.



httpd-test project is using this Perl framework for testing C modules

for Apache 1.3 and 2.0 and the server itself. And of course originally

it was developed for mod_perl 2.0. The same test suite can work with

httpd 1.3 and httpd 2.0. For more info see:

http://perl.apache.org/preview/modperl-site/docs/2.0/devel/testing/testing.html



Once we release the new modperl site (hopefully in a few weeks) this URL

will appear as:

http://perl.apache.org/docs/2.0/devel/testing/testing.html



I've started mentioning XP in this doc and mention reasons for a need to

test, but more work in needed so your help is very welcome.



To get the framework grab the httpd-test rep from cvs or the snapshot:

http://cvs.apache.org/snapshots/modperl-2.0/



also see:

http://cvs.apache.org/viewcvs.cgi/httpd-test/perl-framework/README?rev=1.8&conte\

nt-type=text/vnd.viewcvs-markup



_____________________________________________________________________

Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker

http://stason.org/      mod_perl Guide   http://perl.apache.org/guide

mailto:stas@...  http://ticketmaster.com http://apacheweek.com

http://singlesheaven.com http://perl.apache.org http://perlmonth.com/