NYCPHP Meetup

[Kenneth Downs]

David Mintz wrote:
> I get the impression that most developers report that they do automated
> testing or they are trying to learn. Only a minority seem to be answering
> flat-out no.
>
> imho one of the major differences between a polished professional and a
> hobbyist is responsible testing. That's why I still kick myself, as sort of
> an eternal wannabe whose day-job description has zero to do with IT, but who
> aspires nevertheless to write code that can be judged competent by any
> standard:  I still haven't gotten the hang of unit testing, though I have
> made some attempts to get religion and vow to keep trying.
>
> It seems that I am not alone. So the question is, why is it hard for some to
> adopt the practice? 

Here is Ken's personal theory as to why it is tough.  I come to this 
theory by examining my own weaknesses and seeing where I seem to have 
things in common with other programmers.

Programmers love to code.  Especially the talented ones, who get "in the 
zone" and can code for hours in a state of deep concentration.  When the 
muse is singing, and code is writing itself, nobody ever wants to 
stop.   Sometimes the results are amazing, sometimes they are not.

The zone is a thrilling and seductive place, but it does not tolerate 
discipline or interruptions.  Stopping every 10 minutes to craft a unit 
test is just plain no fun.  So it doesn't get done.

This is not the entire explanation, but I think it is true part of the time.

Another explanation is the basic human inability to see the limitations 
of our own efforts.  Software is by its nature complex and pieces 
interract in ways we do not predict or intend.  Unit tests and 
integration tests allow a programmer to nail these down and make the 
software very robust, but when you're doing the testing you're not 
coding the next feature, and I think we just love to code the next feature.

> One thing that occurs to me is that maybe it isn't
> really that easy to write good tests. We've all seen examples of how to test
> a function that returns the sum of x + y -- thanks a lot. It's a little
> harder to create simulated http environments complete with cookies and
> sessions -- though people (e.g., the ZF team) have done wonderful things to
> make it easier -- and forsee all the use cases in a complex app. Evidence
> for the proposition that it's hard to write an exhaustive set of tests is
> that you have products like the Zend Framework which is unit-tested to death
> before release, and then the next release brags that 171 bugs were fixed.
>   

This is probably more value to the x+y example than meets the eye.  The 
x+y example is easy to illustrate because you have a function that 
returns a value.  You can make a series of tests that codify what should 
happen for all manner of good and bad inputs, and you're done.

The trick to the other more difficult situations is to learn to cast 
them in x+y terms.  If I have trouble with a cookie-browser situation, 
how can I make it simple enough to test as an x+y situation?  If I 
cannot make it simple enough to test /then I probably cannot get it to 
work right!/ 

Consider a web server.  A page request is the input, and the returned 
HTML is the output.  If your application is well designed, it must be 
possible to craft query requests and measure the returned HTML against 
an expected value.  If the page is too complicated to do this, then comp 
sci 101 is our friend: we break it down into pieces that can be tested 
individually.  This can be as simple as inserting HTML comments that 
mark certain areas so they can parsed out and compared against expected 
values.

Another example would be databases and calculated values.  How do you 
test that as if it were an x+y situation?  It's pretty simple actually.  
Craft a test system that makes inserts, updates, deletes, and then 
retrieves rows and compares them to the desired output.  If the rows 
come back ok, the test passes.

So I would say in conclusion it is all about learning to break the whole 
thing down into pieces that can be tested like the toy examples in the 
books.

>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> New York PHP User Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/show_participation.php


-- 
Kenneth Downs
Secure Data Software
ken at secdat.com  www.andromeda-project.org www.secdat.com
Office: 631-689-7200
Cell: 631-379-0010
Fax: 631-689-0527

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20090506/c14cbb76/attachment.html>