[Newbies] Unit testing

[Jerome Peace]

--- On Sun, 4/18/10, Sean P. DeNigris <sean at clipperadams.com> wrote:

> From: Sean P. DeNigris <sean at clipperadams.com>
> Subject: [Newbies] Unit testing
> To: beginners at lists.squeakfoundation.org
> Date: Sunday, April 18, 2010, 1:33 AM
> 
> After doing a lot of snooping around my image, I was
> surprised by the unit
> tests I saw (this is not a criticism, but me wanting to
> understand and
> contribute to the Squeak philosophy).  Coming from
> C++, and then Ruby, the
> conversation is (for unit tests) to mock/stub out
> absolutely everything that
> the object-under-test interacts with; of course augmented
> by
> integration/functional/acceptance tests to verify the
> actual interactions. 
> Dependency injection is in full force (which I always find
> ugly and
> complicated, but does make testing very easy).
> 
> Yet in Squeak's core, I found things like
> KernelTests-Chronology
> StopwatchTest>>testActive, which sets a delay and -
> gasp - actually waits
> for the time to tick by.  I would've always created a
> clock double to
> pretend that time had passed (even though, for the few
> seconds that passed
> in these particular tests, probably not a big deal; but
> when you add similar
> tests up all over the image?).
> 
> Also, in Ruby, there is a huge push (e.g. rspec community)
> to write tests
> that a prospective library user could come along and see
> clear examples of
> how to use the classes; not to mention the BDD craze (which
> I've seen a few
> libraries for, but don't seem to be widely used) that helps
> refocus design
> based on behavior.
> 
> Anyway, I'm presenting this because I am blown away by the
> Dynabook/Open
> Personal Computing vision.  I'm clear that all the
> objects in my world want
> to live in a Squeak image.
> So it's important to me to:
> * spur conversation and growth
> * make sure code that I write fits with the spirit of the
> community
> 
> Thanks.
> Sean DeNigris
> --
Smalltalk is thirty years old. It is not up to speed on testing technology.
Some of the newer modules do better. I understand Seaside tests extensively. I don't know if they use mocks or not.

Good testing needs to be designed in to code. I do a lot of bug tracking. Find bugs in squeak is not too hard. Find good ways to fix them or to test fixes or code is difficult. Often code authors have gone on to other things. 

Further, building code that allows dependency injection is not how squeak got built. Thus the tests you see are clumsy acceptance tests rather than cool sunit stuff. No one here has gotten around to noting the difference. 

Also, squeak is sorely deficient in integration testing. Lots of bugs come because module A does not make the same assumptions as module B. Both assuming the world has been built to accommodate their model of it.

That said I can't divorce myself from the squeak way of doing things. The ability to code and test in a tight loop is addictive. Like you, I would like to see the testing situation improve.

More people here are beginning to become test infected. So I have hope.

Cheers.

Yours in curiosity and service, --Jerome Peace