This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Testing and debugging Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

There's another thread in comp.lang.smalltalk on debugging and testing. There's a level of misunderstanding between Smalltalk developers and people who've never used a language like Smalltalk - you'll see that in comments like this:

Debuggers are great tools, the but the thing to ask whenever you want to use one is why it isn't easier to just write a test case. In some projects it is. In others, well, we all know when we are working in a project like that, but there are things that we can do to make it easier.

It's not that debuggers are bad, its just that they can desensitize us. It's like downing a beer and sleeping on the beach; we shouldn't be surprised if we wake up with a sunburn. We can start to think that our code is pretty good when in fact its really pretty lousy because we've ignored concrete evidence that it could be easier to understand and test.

Now, I know why people who mostly work in languages like C# and Java say this - their debuggers are forensic tools - the patient has died, and the best that you can do is figure out what killed him. Smalltalk developers have a different tool at their disposal - the Smalltalk debugger

The Smalltalk debugger is both a debugger and and code browser. With Smalltalk, the developer becomes a surgeon - the patient isn't dead, he's been sedated. We can look at what's wrong with him, and fix him up while we look at him - in the debugger. That's why most of these conversations end up with people talking past each other. In Smalltalk, we can write the test - and when it fails, we end up in the debugger - from where we can patch the code (or the test, depending on circumstances) up and move along.