Dean -- I think you are overstating the case against unit tests.

  1) Complex unit tests, like complex code, are in general bad. Simple
     units test, like simple code, are better. And there are many ways to
     make complex unit tests simpler.

  2) If it takes to long to run the unit tests, thats a sure sign that
     you've got poor tests, poor code or both. For example, my implementation
     of PerlUnit has 74 tests that /comprehensively/ cover the implementation
     code and all 74 tests run in under one second. At the other end of the
     spectrum, there is something /seriously/ wrong with the fact that it
     takes over an /hour/ to run the Refactoring Browser tests. But slow
     tests are better than no tests.

  3) User interface code /can/ be more difficult to unit test, but that is
     mostly because you need a different set of testing techniques in your
     bag of tricks when you test UI code. Once you learn to adjust your
     testing approach, testing UI code isn't any harder than testing anything
     else. As far as networking code goes, I hadn't heard that testing
     networking code was problematic for people; it has never given me any
     problems. If you come across code that you think is truly /impossible/
     to test, post it to the list or send it to me--I am sure we can come up
     with something.

I agree with Ned that tests should be optional, if for no other reason than that they are currently so uncommon--most of the packages on SqueakMap don't have tests. But I would still like to see tests as a central feature of packages and SqueakMap, so that when they /are/ there we can make full use of them. (Including stuff like the feedback mechanism that CPANplus uses.)

david


At 07:52 PM 11/12/2002 -0500, you wrote:
>
>While I agree that the idea of including SUnits with a package so that
>everyone who installs it can verify their own installation, I would
>like to mention some limitations and undesirable features of this
>approach, and see what others think:
>
>  1) The code for the test cases can often be larger and more complex
>     than the code to implement the package features.
>
>  2) The test cases can take a LONG time to run for complex code.
>
>  3) Some things are very difficult or impossible to programmatically
>     test. (i.e. user interface code, networking code, etc.)
>
>For these reasons and probably a bunch of others I haven't listed,
>automated tests aren't always practical, or even if the tests are
>written, the tests may not be appropriate for everybody who wants to
>use the package to run.
>
>I really like the direction that the image factoring/modularization
>work is currently going (as in SM and DVS), but I also really like
>that an "official release" image of Squeak like 3.2-4956 has been
>fairly well excercised as a whole, and can be trusted as fairly
>stable and reliable "right-out-of-the-box".
>
>I'm not too excited about the idea of having to take an "official
>release" of the Squeak kernel and add packages in my own unique
>combination to get the image I want then have to spend lots of time
>verifying my newly constructed image.
>
>What does the rest of the community think?
>
>				-Dean Swan
>
>
>-----Original Message-----
>From: Michael Rueger [mailto:m.rueger at acm.org]
>Sent: Tuesday, November 12, 2002 12:41 PM
>To: squeak-dev at lists.squeakfoundation.org
>Subject: Re: Image factoring
>
>
>
>
>Norton, Chris wrote:
>> [ snip Colin's interesting discussion of splitting PWS from Squeak ]
>> 
>> You raise a bunch of good points, Colin.  But one thing that concerns me,
>> even more than *who* maintains a package, is that there is no *proof* that a
>> package will work, once you get it back into your image.
>
>SUnits anyone?
>Seriously, splitting up the image is a strong motivation to finally have 
>at least basic SUnit tests for every package.
>
>Michael
>
>
>
--
David Farber
dfarber at numenor.com