I arrived a bit late, or Blaine started early - on with the talk. Where does pain come from? Tight schedules, fragile design, inexperience, unclear vision, poor coding practices, broken contracts. Despite your best intentions, some of this creeps in. You end up building up a "software debt" where you least expect it. The Tools? SUnit, Reflection, Version Control. There are the ancillary things you get from reflection (MethodWrappers, etc).

SUnit can be used to help "enforce contracts". It helps the team remember decisions that might otherwise be forgotten. Using reflection, Smalltalk makes it easy to check existing methods for various things - calls to things that should not happen at runtime, etc (eg - #halt left in the code).

Dumb Bugs Detection

SUnit and Lint are your medicine for finding stupid stuff. Helps you find code smells that have arisen via poor coding practices. The nice thing about Lint in Smalltalk is that it has a programmatic API - you can set up ad-hoc Lint runs that are scripted, without having to use a UI. The RB, of course, has a UI for it.

MethodWrappers can raise flags when contracts are broken. They are a good way of checking legacy code - you can add before and after blocks to methods, which can check pre/post conditions. You'll want to make sure that you unwrap the method wrappers afterwards, of course.

I'm missing some of the flavor of this talk - Blaine is moving from the presentation back to his Squeak image to show code and tests, and demonstrate. So bear in mind, with each thing (like Method Wrappers), he's showing live examples.

Broken Window Detection

SUnit and Metrics are your "canaries in the legacy code mine". You don't want to use these as sticks to beat people with; rather, you want to find out what's happening. Blaine recommends these three:

• Cyclomatic Complexity - good for finding spaghetti code
• Average Message Sends - lower scoring ones turn up data only objects
• Coupling - take all your message sends, and compare it to the methods your class actually implements. You end up finding "god" objects.

Keep the metrics simple, because complex metrics will just add complexity to your process.

SUnit and Source control interrogation- exposes volatile objects and code smells in the system. It can turn up possible objects for code review. Pragmas allow you to add meta data to methods. Helps pinpoint "private" violations, and class to deprecated methods. It's better than relying on method protocols.

Selling Reflective Testing

You need team consensus for metrics - what will you use, and how. You want to start simple, so you can get early success. Be positive instead of using it as a stick. Start encouraging refactoring sessions.