Hi Dennis, What do you think about the approach shown in this screencast: http://www.pharocasts.com/2011/02/stringcalculator-kata.html ?
I'm far away from being an Smalltalk developer, but I tried to show a TDD process to solve this simple kata. Rafael Luque 2013/6/7 Dennis Schetinin <[email protected]> > I don't remember exactly where and when, but I think we've discussed the > Laser Game tutorial already. I told this before, and I (after reviewing the > tutorial again) should repeat it again: actually, this tutorial doesn't > show TDD. I can explain my opinion in detail if someone's interested, but > in general, that's simply an up-front design approach with some automatic > testing. It's not even "Test-First" approach most of time. > > Disclaimer: I don't mean the tutorial and/or the design approach used > there are bad. I like this tutorial. It's really very good: it shows many > aspects for Smalltalk programing, it shows how to use debugger and > inspectors properly. I borrowed many ideas from there for my Smalltalk > programming course… It's just not TDD, not "pure" TDD at least. > > > > -- > > Best regards, > > > Dennis Schetinin > > > 2013/6/7 <[email protected]> > > Paul Davidowitz wrote: >> >>> It seems to me that a big reason for developing via writing tests first >>> (Test Driven Development) is that the tests serve as a debugging tool -- >>> if a test breaks, then the last piece of (non-test) code that change is >>> likely the culprit. But with the powerful debugging environment that >>> comes with Smalltalk, I am wondering of the utility of TDD (TDD is big >>> in the Ruby camp perhaps for a reason). After all, writing and >>> re-writing the tests becomes quite a non-trivial chore (not to mention >>> that the tests themselves could be buggy). So my question: Is it ok in >>> Smalltalk to write tests afterwards? Is it even perhaps recommended? >>> >>> - Paul >>> >>> >>> >>> >> Actually some Smalltalk'ers consider the debugger a major facilitator of >> TDD by mostly coding from within the debugger. >> 1. Before writing any application code, write a test. >> 2. Execute that test straight away. Of course it fails because you >> haven't written any application code. >> 3. Up comes the debugger - now "from within the debugger" add the >> application code needed to satisfy the test. >> 4. Repeat. >> >> A good demonstration of this is Stephan Wessels' Laser Game tutorial [1] >> (but you'll temporarily need to revert to Squeak 3.9 to do it) >> cheers -ben >> >> >> >
