Wed, 31 Aug 2005
I've long had affection for PNSQC. It's a regional conference, but the only evidence of that is its size. The content is more like what you'd expect from a national conference. It's in Portland, Oregon, which is a little bit of a hotbed of Agile: Ward Cunningham, Jim Shore, Rebecca Wirfs-Brock, Steven Newton - all these people are Portland locals (though I suppose Ward may be completely gone now). Of the six keynote and invited speakers, four are pretty firmly associated with Agile: Mike Cohn, Esther Derby, Linda Rising, and me.
They have a PDF brochure.
October tenth through the twelfth.
Sometimes when demoing Ruby, I get the reaction that runtime typing is too error-prone. I'm not alone in responding by saying that unit tests will catch the bugs a static typechecker would, plus others. So why use both?
That's something of a flip response, and it's not really true. Here's an example I stumbled over while working on a chapter of Scripting for Testers.
Here's code that sets a variable:
Here's one of the methods that consume it:
Here's how I called that method in a test:
The test passed. All the methods were tested, and all the tests passed. But the program failed:
The problem is that I unit-tested
The root cause of the bug was my cretinous choice of a variable
name. I should not have named a variable expected to contain
However, it seems to me that such errors will be caught if the whole-system tests exercise every call in the app. Suppose you're doing TDD starting from business-facing tests. Every call in the app would have to be traceable to a test whose failure motivated (perhaps very indirectly) that call, therefore every call in the app would be exercised by the complete suite (modulo some smallish background rate of human coding/design error), therefore there is no need for typechecking. But I'm perhaps being too flip.
P.S. Reviewers of Scripting: the example has been slightly tweaked for this posting.