--- On Sun, 4/18/10, Sean P. DeNigris sean@clipperadams.com wrote:
From: Sean P. DeNigris sean@clipperadams.com Subject: [Newbies] Unit testing To: beginners@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